Automobile risk assessment using the average velocity of relevant vehicles

ABSTRACT

Systems and methods for using a vehicle&#39;s relative speed to determine an automobile insurance risk assessment rating are provided. According to certain aspects, an average velocity may be calculated, either from real-time or historical telematics data, for a group of vehicles traveling in the same direction on a roadway. Additionally, an average velocity differential for a target vehicle may be determined based upon the average velocity of the group of vehicles. Moreover, based upon the average velocity differential, an automobile insurance risk assessment rating for an individual may be determined which may cause a change in the individual&#39;s automobile insurance premium. Further, recommendations on how to improve the individual&#39;s automobile insurance risk assessment rating may be provided to the user via the user interface of an electronic device associated with the individual.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication No. 62/504,180, entitled “Automatic Insurance RiskAssessment Using Relative Speed,” filed May 10, 2017, the disclosure ofwhich is hereby expressly incorporated by reference herein in itsentirety.

TECHNICAL FIELD

The present disclosure relates to using a vehicle's ambient speed todetermine an automobile insurance risk assessment rating for anindividual. More particularly, the present disclosure relates todetermining an average velocity differential between a vehicle and agroup of surrounding vehicles based upon real-time or historical data todetermine a risk assessment rating.

BACKGROUND

Generally, vehicles may travel at different velocities on the samesection of a roadway. Although there may be a posted speed limit towhich vehicle operators should adhere, other road conditions (e.g., roadconstruction, weather, traffic, etc.) as well as the velocity of othervehicles on the same roadway in the vicinity of the vehicle may causevehicle operators to regularly deviate from the posted speed limit.Therefore, current systems that assess the risk of a particular vehicleoperator by comparing the velocity of the vehicle to the posted speedlimit may have several drawbacks.

BRIEF SUMMARY

In contrast to conventional systems, the embodiments of the presentdisclosure are related to assessing vehicle operator risk by comparingthe velocity of the vehicle to other proximate vehicles, taking otherfactors into account such as the current weather and road conditions. Todo so, the present disclosure generally relates to measuring aparticular vehicle's velocity with reference to other vehicles todetermine the vehicle's relative speed. A vehicle's relative speed maybe calculated, for example, by collecting velocity data (e.g., in theform of collected telematics data) that is associated with other nearbyvehicles, and determining a vehicle's speed relative to these nearbyvehicles driving at similar times, locations, and/or directions. Oncecalculated, a vehicle's relative speed is used to assess the risk ofthat particular vehicle's operator. Embodiments of example systems andmethods are summarized below. The techniques summarized below mayinclude additional, less, or alternate actions, including thosediscussed elsewhere herein.

In one aspect, a computer-implemented method for updating insurance datamay be provided. The method may include one or more processors (1)receiving telematics data associated with one or more vehicles, the oneor more vehicles including a target vehicle; (2) determining an averagevelocity of the other vehicles excluding the target vehicle; (3)comparing a velocity of the target vehicle to the average velocity ofthe other vehicles; and/or (4) updating insurance data associated withthe target vehicle or a driver associated with the target vehicle basedupon the comparison of the velocity of the target vehicle to the averagevelocity of the other vehicles. The method may include additional, less,or alternate actions, including those discussed elsewhere herein.

In another aspect, a remote server for updating insurance data may beprovided. The remote server may include (1) a communication unitconfigured to receive telematics data associated with one or morevehicles, the one or more vehicles including a target vehicle; and (2) aprocessor unit configured to: (a) determine an average velocity of theother vehicles excluding the target vehicle; (b) compare a velocity ofthe target vehicle to the average velocity of the other vehicles; and/or(c) update insurance data associated with the target vehicle or a driverassociated with the target vehicle based upon the comparison of thevelocity of the target vehicle to the average velocity of the othervehicles. The remote server may include additional, less, or alternatefunctionality, including that discussed elsewhere herein.

In yet another aspect, a tangible, non-transitory computer-readablemedium for updating insurance data may be provided. The tangible,non-transitory computer-readable medium may include instructionsexecutable by one or more processors that, when executed by the one ormore processors, cause the one or more processors to (1) receivetelematics data associated with one or more vehicles, the one or morevehicles including a target vehicle; (2) determine an average velocityof the other vehicles excluding the target vehicle; (3) compare avelocity of the target vehicle to the average velocity of the othervehicles; and/or (4) update insurance data associated with the targetvehicle or a driver associated with the target vehicle based upon thecomparison of the velocity of the target vehicle to the average velocityof the other vehicles. The instructions may include or directadditional, less, or alternate functionality, including that discussedelsewhere herein.

Systems or computer-readable media storing executable instructions forimplementing all or part of the systems and/or methods described hereinmay also be provided in some embodiments. Systems for implementing suchmethods may include one or more of the following: a special-purposecomputing device, a mobile computing device, a personal electronicdevice, an on-board computer, one or more remote servers or a cloudcomputing system, one or more remote data storage entities, one or moresensors, one or more communication modules configured to communicatewirelessly via radio links, radio frequency links, wireless or digitalcommunication channels, and/or one or more non-transitory, tangibleprogram memories coupled to one or more processors of thespecial-purpose computing device, mobile computing device, personalelectronic device, on-board computer, and/or one or more remote serversor cloud computing system. Such program memories may store instructions,which, when executed by the one or more processors, may cause a systemdescribed herein (or individual components of such a system) toimplement part or all of one or more techniques described herein.Additional or alternative features described herein may be included insome embodiments.

Advantages will become more apparent to those of ordinary skill in theart from the following description of the preferred aspects which havebeen shown and described by way of illustration. As will be realized,the present aspects may be capable of other and different aspects, andtheir details are capable of modification in various respects.Accordingly, the drawings and description are to be regarded asillustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF DRAWINGS

The figures described below depict various aspects of the presentdisclosure. It should be understood that each figure depicts anembodiment of a particular aspect of the present disclosure. Further,wherever possible, the following description refers to the referencenumerals included in the following figures, in which features depictedin multiple figures are designated with consistent reference numerals.

There are shown in the drawings arrangements which are presentlydiscussed, it being understood, however, that the present embodimentsare not limited to the precise arrangements and instrumentalities shown,wherein:

FIG. 1 depicts an exemplary automobile insurance risk assessment ratingsystem, in accordance with aspects of the present technology.

FIG. 2 depicts a block diagram of an exemplary remote server, inaccordance with aspects of the present technology.

FIG. 3 depicts a block diagram of an exemplary electronic device, inaccordance with aspects of the present technology.

FIGS. 4A and 4B depict exemplary scenarios of the environmentsurrounding a vehicle in which an automobile insurance risk assessmentrating system may be implemented, in accordance with aspects of thepresent technology.

FIGS. 5A and 5B each depict an exemplary table of real-time telematicsdata for a group of vehicles, in accordance with aspects of the presenttechnology.

FIGS. 6A, 6B, and 6C each depict an exemplary table of historicaltelematics data for a group of vehicles, in accordance with aspects ofthe present technology.

FIG. 7 depicts an exemplary flow diagram associated with assessing anautomobile insurance risk rating, in accordance with aspects of thepresent technology.

FIG. 8 depicts an exemplary flow diagram associated with assessing anautomobile insurance risk rating, in accordance with aspects of thepresent technology.

FIG. 9 depicts an exemplary user interface associated with displayingautomobile insurance risk assessment information, in accordance withaspects of the present technology.

The figures depict aspects of the present invention for purposes ofillustration only. One skilled in the art will readily recognize fromthe following discussion that alternate aspects of the structures andmethods illustrated herein may be employed without departing from theprinciples of the invention described herein.

DETAILED DESCRIPTION

The present embodiments relate to, inter alia, using a vehicle'srelative speed to determine an automobile insurance risk assessmentrating for one or more vehicle operators whom may be insured by aninsurance provider. Again, there is typically a posted speed limit thatvehicles should adhere to, but other conditions (e.g., roadconstruction, weather, traffic, etc.) and the velocity of other vehicleson the same roadway may cause vehicle operators to deviate from thisposted speed limit. Therefore, risk is better assessed by comparing adriver's performance to other similarly-situated drivers (and/orautonomous vehicles) rather than a static, unchanging constant such as aposted speed limit.

The aspects described herein leverage collected vehicle telematics data(which may include or indicate vehicle velocity) to determine an averagevelocity for a group of vehicles that are undergoing similar conditionsas a particular “target” vehicle for which a risk assessment is sought.For example, these conditions may include other vehicles in the vicinityof the target vehicle (e.g., a threshold distance from the targetvehicle) and/or vehicles traveling in the same direction on the sameroadway and at the same time as the target vehicle (and thus beingexposed to the same weather and road conditions). Based upon the averagevelocity of the group of vehicles, an average velocity differential maybe calculated as a difference between the target vehicle's velocity andthe average velocity of the group of vehicles. The telematics data mayinclude vehicle speed, acceleration, cornering, braking, direction,route, heading, GPS information (e.g., speed and location), otherlocation data, and other information.

Additionally, the aspects described herein may determine an automobileinsurance risk assessment rating for an insured individual (i.e., thevehicle operator) based upon the aforementioned average velocitydifferential. This calculated automobile insurance risk assessmentrating may then be used by an insurance provider to determine and/orupdate the insured individual's automobile insurance premium. Moreover,the aspects described herein may alert the insured individual of achange in the automobile risk assessment rating and provide an updatedautomobile insurance premium via an electronic device that is associatedwith the individual and/or the vehicle. Further, the aspects describedherein may provide suggestions or a set of recommendations to theinsured individual to improve his or her automobile insurance riskassessment rating, thereby lowering the insured individual's automobileinsurance premium.

Exemplary Technical Advantages

The aspects described herein offer numerous benefits. In particular,vehicle operators may be more motivated to drive or operate a vehicle(e.g., an autonomous vehicle) in a safer manner if there is a risk thattheir automobile insurance premium may increase. Additionally, theincentive of obtaining a lower automobile insurance premium because ofsafer driving or vehicle operation may also motivate individuals todrive in a safer manner. Further, safer roadways may prevent accidentsand collisions, which may in turn prevent property damage, injury, anddeath. It should be appreciated that these are only some examples, andthat other benefits are also envisioned.

The aspects discussed herein address challenges that are specific todetermining an automobile insurance risk assessment rating. Inparticular, these challenges relate to difficulties related toeffectively evaluating an individual's driving behavior or vehicleoperation to properly assess risk, and in turn accurately calculating anautomobile insurance premium based upon this risk. Conventionally, anautomobile insurance premium may not change during the term of theautomobile insurance policy unless some intervening event occurs, suchas a claim being made by an insured individual or the insured individualbeing cited for traffic violations such as speeding, for example.Consequently, an individual that has not been involved in a collision orhas little or no tickets on his record over the past few years mayobtain an automobile insurance policy with a low premium, although theindividual may actually exhibit very poor (i.e., high risk) drivingbehavior. For example, an individual who typically speeds may not haveany speeding tickets on record because the individual uses a radardetector. In other words, even though the individual does not have anyspeeding tickets on record, the individual does not actually exhibitsafe driving behavior.

Therefore, the techniques discussed herein use a target vehicle'srelative velocity to determine a relative velocity of a target vehicleas an average velocity differential between the target vehicle and othervehicles traveling proximate to the target vehicle and/or on the sameroadway at the same time as the target vehicle. In various aspects, theaverage velocity differential may be based upon an average velocity ofthe other vehicles, which may be calculated based upon the real-timevelocity of the other vehicles or based upon stored historical velocitydata. Additionally, the various aspects described herein may determinean automobile insurance risk rating for the operator of the targetvehicle based upon this average velocity differential of the targetvehicle, which may result in adjustments to the target vehicleoperator's automobile insurance premium. Thus, individuals will bemotivated to be safer drivers because of the risk of having to payhigher premiums and the incentive of lower premiums.

Further, because the aspects described herein employ the collection,compiling, storing, and displaying of data associated with a targetvehicle and its operator, the aspects are necessarily rooted in computertechnology to overcome the noted shortcomings that specifically arise inthe realm of using a vehicle's relative speed to determine an automobileinsurance risk assessment rating. Accordingly, the aspects describedherein provide advantages via the ability to access real-time telematicsdata and/or historical telematics data for several vehicles.

Similarly, the aspects described herein also provide improvements tovarious technical fields. Namely, these technical fields include sensordata processing, generating an automobile insurance risk assessmentrating, and adjusting a calculated automobile insurance premium basedupon the automobile insurance risk assessment rating. Instead of merelybeing performed by hardware components using basic functions, theaspects described herein employ a unique combination of complex stepsthat go beyond the mere concept of simply retrieving and combining datausing a computer.

In particular, the hardware components described herein may capturesensor data, analyze the sensor data, calculate a relative targetvehicle velocity with respect to other nearby vehicles, calculate anautomobile insurance risk assessment rating and premium, communicate theupdated automobile insurance risk assessment rating and premium to theindividual via an electronic device, and provide the individual withrecommendations on how to improve the individual's automobile insurancerisk assessment rating, thus lowering the individual's automobileinsurance premium. This combination of elements further imposesmeaningful limits in that the operations are applied to improving sensordata processing and determining an updated automobile insurance riskassessment rating and premium for an individual, so that the individualmay be motivated to drive more safely, improve traffic safety, andreduce the risk of an accident, injury, or death to the individual orothers.

The aspects described herein may support dynamic, real-time, or nearreal-time analysis of any captured, received, and/or detected data. Inparticular, an electronic device (e.g., a smart phone) may receive dataabout an updated automobile insurance risk assessment rating and premiumfor an individual in real-time or near real-time, and may generaterecommendations to improve the individual's automobile insurance riskassessment rating and premium in real-time or near real-time. In thisregard, a vehicle operator is afforded the benefit of an insurancepremium that represents an accurate representation of his/her drivingbehavior, as well as recommendations to improve his/her driving behaviorto create a safer vehicle environment.

System Overview

FIG. 1 depicts an exemplary automobile insurance risk assessment ratingsystem, in accordance with aspects of the present technology. In variousaspects, the system 100 may include one or more network(s) 110, remoteserver(s) 150, database(s) 160, one or more smart infrastructurecomponents 155, and one or more vehicles 120, 130, and 140, each ofwhich is associated with an electronic device 125, 135, and 145,respectively. Although FIG. 1 illustrates one network 110, one remoteserver 150, one database 160, one smart infrastructure component 155,and three vehicles 120, 130, and 140 with associated electronic devices125, 135, and 145, it is to be understood that system 100 may includeany suitable number of such components.

In certain embodiments, the network(s) 110 may support any suitablenumber and/or type of data communication via any standard or technology(e.g., GSM, CDMA, TDMA, WCDMA, LTE, EDGE, OFDM, GPRS, EV-DO, UWB,Internet, IEEE 802 including Ethernet, WiMAX, Wi-Fi, Bluetooth, andothers). The network(s) 110 may also be one or more private or localnetworks or dedicated frequency bands.

Each of electronic devices 125, 135, and 145 may communicate via thenetwork(s) 110 via radio links 170 a-170 c, respectively. The electronicdevices 125, 135, and 145 may additionally or alternatively communicatewith one other and/or the remote server 150 via the network(s) 110. Forexample, the electronic devices 125, 135, and 145 may be located in eachof vehicles 120, 130, and 140, respectively, and thus collect andtransmit telematics data for each of vehicles 120, 130, and 140 to theremote server 150. In various aspects, the electronic devices 125, 135,and 145 may be implemented as any suitable type of device, which may beintegrated as part of the vehicle in which it is located or as aportable device separate from the vehicle. For example, the electronicdevices 125, 135, and 145 may be implemented as mobile electronicdevices, such as smartphones or as integrated components such ason-board vehicle computers. The vehicles 120, 130, 140 may be humanoperated, or autonomous or semi-autonomous vehicles, in someembodiments. It should be appreciated that other types of electronicdevices and/or mobile devices are envisioned, such as notebookcomputers, tablets, phablets, GNSS-enabled devices, smart watches, smartglasses, smart bracelets, wearable electronics, PDAs (personal digitalassistants), pagers, computing devices configured for wirelesscommunication, etc.

Moreover, although not shown in FIG. 1, one or more of vehicles 120,130, and 140 may likewise communicate with other vehicles, otherelectronic devices 125, 135, and 145, one or more smart infrastructurecomponents 155, and/or the remote server 150 directly (e.g., via aseparate link not shown in FIG. 1 for purposes of brevity) and/orindirectly (e.g., via one or more electronic devices 125, 135, and 145as a “relay” or “proxy” and/or via one or more via network(s) 110).Embodiments in which one or more of vehicles 120, 130, and 140 maycommunicate with other devices, such as remote server 150, may beparticularly useful when one or more of vehicles 120, 130, and 140 isconfigured to measure, generate, collect, and/or transmit telematicsdata independently of the electronic devices 125, 135, and 145. Forexample, embodiments include one or more of vehicles 120, 130, and 140being configured with any suitable number and/or type of sensors tomeasure telematics data. This telematics data may include the same typeof data measured by the electronic devices 125, 135, and 145 ordifferent types of data. For example, one or more of vehicles 120, 130,and 140 may include specialized sensors that may be configured tomeasure different metrics (or the same metrics) as the one or moreelectronic devices 125, 135, and 145.

These specialized and/or integrated sensors are not shown in FIG. 1 forpurposes of brevity. However, examples of the telematics data generatedby such sensors associated with one or more of vehicles 120, 130, and140 may include data measured by radar, ultrasonic sensors, LIDAR,global navigation satellite system (GNSS) enabled devices, etc.Therefore, the telematics data may include data indicating the relativespeed and range between a particular vehicle and surrounding vehicles,which may be used (e.g., via remote server 150) to identify the velocityof other vehicles proximate to a target vehicle. Additionally oralternatively, the sensors associated with one or more of vehicles 120,130, and 140 may generate data (which is then included in a telematicsdata transmission) indicative of changes in the vehicle's geographicposition over time, changes in the vehicle's velocity over time, weatherconditions, road conditions, etc. The details of the telematics data andadditional examples of the type of information that may be included inthe telematics data transmission are further discussed below.

Smart infrastructure component 155 may be implemented as any suitabletype of traffic infrastructure component configured to receivecommunications from and/or to send communications to other devices, suchas other vehicles 120, 130, 140, other electronic devices 125, 135, and145, and/or the remote server 150 directly (e.g., via a separate linknot shown in FIG. 1 for purposes of brevity) and/or indirectly (e.g.,via link 170 e in conjunction with one or more via network(s) 110 or viaone or more electronic devices 125, 135, and 145 functioning as a“relay” or “proxy”), for example. In various aspects, smartinfrastructure component 155 may be implemented as a traffic light, arailroad crossing light, a construction notification sign, a roadsidedisplay configured to display messages, a billboard display, etc.

In various aspects, the smart infrastructure component 155 may beconfigured with any suitable number and/or type of sensors to measuretelematics data. This telematics data may include the same type of datameasured by the electronic devices 125, 135, and 145 (and/or thevehicles 120, 130, and/or 140), or different types of data. For example,the smart infrastructure component 155 may include integrated and/orspecialized sensors that are not shown in FIG. 1 for purposes ofbrevity. Similar to the data measured by one or more of vehicles 120,130, and/or 140 as discussed above, examples of the telematics datagenerated by sensors associated with the smart infrastructure component155 may include data measured by radar, ultrasonic sensors, LIDAR,global navigation satellite system (GNSS) enabled devices, etc. However,given that the smart infrastructure component 155 may be stationary andhave a dedicated source of AC power compared to the vehicles 120, 130,and/or 140, aspects include smart infrastructure collecting, measuring,generating, and/or transmitting telematics data in a manner thatleverages these advantages. For example, the smart infrastructure 155may be configured to utilize a dedicated connection to the remote server150 given that it is not moving and cellular tower handoffs are notrequired. To provide another example, the smart infrastructure component155 may be configured with more accurate, sophisticated, and/orpower-intensive sensors or other components than cannot feasibly beimplemented using a vehicle's battery-powered system.

In various aspects, the telematics data measured by the smartinfrastructure component 155 may likewise include data indicating therelative speed and range between a particular vehicle and surroundingvehicles, which may be used to identify other vehicle's speed proximateto a target vehicle. Additionally or alternatively, the sensorsassociated with the smart infrastructure component 155 may generate data(which is then included in a telematics data transmission) indicative ofchanges in one or more vehicle's geographic position over time, changesin one or more vehicle's velocity over time, weather conditions, roadconditions, etc.

Remote server 150 may be configured to communicate with one or morevehicles 120, 130, and/or 140, one or more electronic devices 125, 135,and/or 145, and/or one or more smart infrastructure components (e.g.,the smart infrastructure component 155) directly and/or indirectly(e.g., via the network(s) 110 using any suitable number and/or type ofwired and/or wireless links, represented in FIG. 1 as link 170 d).Similarly, links 107 a-170 c also represent any suitable number and/ortype of wired and/or wireless links, although a single link 170 a-170 din shown in FIG. 1 for purposes of brevity. The remote server 150 mayalso interface with a database 160 via link 165. In another aspect, thedatabase 160 may be integrated as part of or otherwise built into theremote server 150. The database 160 may contain or store any suitabletype and amount of various information and data. In one implementation,the database 160 may store historical telematics data associated with aplurality of other vehicles that were previously operated by a pluralityof drivers. The database 160 may also store other information such asautomobile insurance policy information, personal information of insuredindividuals, etc.

In various aspects, each of the one or more vehicles 120, 130, and/or140, one or more electronic devices 125, 135, and/or 145, and/or one thesmart infrastructure component 155 may transmit a unique identifier(e.g., in the telematics data transmission or as part of the telematicsdata itself) such that the telematics data transmitted by each devicemay be later correlated to each device via the remote server 150. Tothis end, aspects include the remote server 150 receiving telematicsdata or other suitable data from one or more components of system 100,such as one or more vehicles 120, 130, and/or 140, one or moreelectronic devices 125, 135, and/or 145, and/or one or more smartinfrastructure components (e.g., the smart infrastructure component155).

The remote server 150 may process this data to track the velocity of oneor more vehicles over time and to determine an average velocitydifferential between a particular (i.e., “target”) vehicle and one ormore other vehicles proximate to the target vehicle driving under thesame driving conditions, time of day, road, etc. Based upon thisanalysis, the remote server 150 may determine a risk assessment ratingfor an insured driver associated with the target vehicle and, based uponchanges in this rating over time, update information associated with theinsured driver's insurance account information, such as premiums,qualifying discounts, etc. The remote server 150 may then transmitinformation related to an automobile insurance risk assessment ratingand/or the insured driver's insurance account information (e.g., anautomobile insurance premium) to one or more of the electronic devices125, 135, and 145. The operation of the remote server 150 is furtherdiscussed below.

Detailed Operation of an Exemplary Remote Server

FIG. 2 depicts a block diagram of an exemplary remote server 200, inaccordance with aspects of the present technology. In one embodiment,remote server 200 may be an implementation of remote server 150, asshown and discussed with respect to FIG. 1. It should be noted that,although only a single server 200 is shown in FIG. 2, this is only oneof many embodiments. In some embodiments, multiple servers 200 may beconfigured to have a logical presence of a single entity, such as aserver bank or an arrangement known as “cloud computing.” Theseconfigurations may provide various advantages, such as enabling nearreal-time uploads and downloads of information as well as periodicuploads and downloads of information. However, for ease of discussionand not limitation, the server 200 is referred to herein using thesingular tense.

In one aspect, the server 200 may include one or more controllers 220that are operatively connected to a data storage device 225, which mayinclude any suitable device such as a database, for example, (e.g., thedatabase 160, as discussed with respect to FIG. 1) via link 228 and/or230, which may include one or more local, wired, wireless, and/or remotelinks. The server 200 may access data stored in the data storage device225 when executing various functions, tasks, and/or techniquesassociated with determining an automobile insurance risk assessmentrating. It should be noted that although FIG. 2 depicts a single datastorage device 225, aspects include the data storage device 225 beingimplemented as multiple physical data storage entities, such as a databank or a data farm.

In various aspects, the data storage device 225 may be adapted orconfigured to store data related to historical telematics data obtainedfrom a plurality of other vehicles that were previously operated by aplurality of drivers. Additionally or alternatively, the data storagedevice 225 may store data related to current and historical automobileinsurance risk assessment ratings for an individual such as insurer dataincluding personal information of the individual, vehicle information(e.g., vehicle make, vehicle model, VIN, etc.), information about theindividual's automobile insurance policy, etc. In various aspects, atleast some of the data stored at the data storage device 225 may bedetermined or generated based upon at least a portion of the historicaltelematics data. The data storage device 225 may additionally oralternatively store other types of data used to calculate a riskassessment rating such as weather-related data, geofence and/or mappingdata, etc.

As further discussed herein, the telematics data collected by the remoteserver 200 from the various electronic devices (e.g., electronic devices125, 135, and 145, as shown in FIG. 1) may be received in a periodic orcontinuous fashion. Thus, the telematics data received by the remoteserver 200 may represent various data points received from eachelectronic device, which are stored in the data storage device 225 andtime-stamped or otherwise time correlated. Additionally, the telematicsdata may be transmitted with an indication of a geographic location ofeach electronic device when the telematics data was transmitted by eachdevice. Thus, the various data points stored in the data storage device225 may also include an indication of a respective geographic locationof each electronic device. In this way, the telematics data pointsstored in the data storage device 225 may be correlated to when andwhere each telematics data point was collected over time.

It should be further noted that, while not shown, additional datastorage devices or entities may be linked to the controller(s) 220 inany suitable manner, e.g., locally and/or remotely. For example,additional databases and/or data storage devices (not shown) that storevarious types of information (such as vehicle accidents, roadconditions, vehicle insurance policy information, driver performance, orvehicle use information) may be locally and communicatively connected tothe controller(s) 220 and/or to the server 210. Additional databases ordata storage devices (not shown) may be remotely communicativelyconnected to the controller(s) 220 and/or to the server 210 via one ormore links 230 to one or more networks 232, and may store datamaintained by third parties (e.g., weather databases, road constructiondatabases, traffic congestion databases, road network databases, IoT(Internet-of-Things) or sensor databases implemented by a city or otherjurisdiction, etc.). In one embodiment, the one or more networks 232 mayinclude the network 110, as shown and discussed with respect to FIG. 1.

In various aspects, the controller 220 may include one or more programmemories 235, one or more processors 240 (which may be called amicrocontroller or a microprocessor), one or more random-access memories(RAMs) 250, and an input/output (I/O) circuit 260, all of which may beinterconnected via an address/data bus 255. It should be appreciatedthat although only one microprocessor 240 is shown, the controller 220may include multiple microprocessors 240. Similarly, the memory of thecontroller 220 may include multiple RAMs 250 and multiple programmemories 235, if desired. Although the I/O circuit 260 is shown as asingle block in FIG. 2, it should be appreciated that the I/O circuit260 may include a number of different types of I/O circuits. The RAM 250and program memories 235 may be implemented as any suitable type ofmemory, such as semiconductor memories, magnetically readable memories,biologically readable memories, or optically readable memories, forexample. The controller 220 may also be operatively connected to thenetwork 232 via the link 230.

The controller 220 may further include a number of applications 261-263stored in its program memory 235. In one embodiment, the applications261-263 comprise one or more software applications or sets ofcomputer-executable instructions that are stored on the programmemor(ies) 235 and executable by the processor(s) 240. For example,program memory 235 may represent a tangible, non-transitorycomputer-readable medium, with each of the applications 261-263including instructions executable by one or more processors (e.g.,controller 220 and/or processor 240) that, when executed by the one ormore processors, cause the one or more processors to perform variousacts as described herein. To provide another example, the applications261-263 may be implemented at least partially in firmware and/or inhardware at the server 200.

The various applications may be executed on the same computer processor240 or on different computer processors 240 in embodiments, as desired.Further, while the various applications 261-263 are depicted as separateapplications, two or more of the applications 261-263 may be integratedas an integral application, if desired. In some embodiments, at leastone of the applications 261-263 may be implemented in conjunction withanother application (not shown) that is stored and executed at theserver 200, such as a navigation or routing application.

In various aspects, the applications 261-263 may include a loggeneration application 261 configured to generate and record logsincluding telematics data collected from various vehicles (i.e., fromelectronic devices associated with the various vehicles) as well aspreviously recorded automobile insurance risk assessment ratings forindividuals. The applications 261-263 may also include a vehiclerelative speed application 262 configured to calculate a targetvehicle's relative speed as an average velocity differential between thetarget vehicle's speed and an average speed of other nearby vehicles. Asfurther discussed herein, this calculation may be performed bycorrelating a vehicle's velocity at a particular location and time toother vehicles at a similar location and time, averaging the velocity ofthe correlated vehicles, and comparing this averaged velocity to that ofthe target vehicle. By performing this calculation over time, server 200may store the target vehicle's relative velocity calculation over time(e.g., in data storage device 225), which may be analyzed to determinean automobile insurance risk assessment rating, as further discussedbelow.

The applications 261-263 may also include an automobile insurance riskassessment rating (RAR) application 263. The automobile insurance RARapplication 263 may be configured to calculate automobile insurance riskassessment ratings and to otherwise update an insured driver's insuranceaccount information. For example, automobile insurance RAR application263 may cause the remote server 200 to access or otherwise communicatewith one or more other servers, databases, etc., to securely updateinsurance account information such as an insured driver's riskassessment rating, qualifying safe driver discounts, and/or automobileinsurance premiums. Again, this information may be updated based uponthe aforementioned relative velocity of a target vehicle and/or therespective automobile insurance risk assessment rating resulting fromthis relative velocity tracked over time. Additionally, the automobileinsurance RAR application 263 may facilitate remote server 200calculating updated automobile insurance risk assessment ratings andautomobile insurance premiums. The details associated with thesecalculations are further discussed below.

Detailed Operation of an Exemplary Electronic Device

FIG. 3 depicts a block diagram of an exemplary electronic device, inaccordance with aspects of the present technology. FIG. 3 illustrates adiagram of an exemplary mobile or other electronic device 300 (such asone of the electronic devices 125, 135, and/or 145 as discussed withrespect to FIG. 1) in which the functionalities as discussed herein maybe implemented. Again, aspects include electronic device 300 beingconfigured to be transported in a vehicle and/or connected to anon-board telematics platform of the vehicle, as discussed herein.Further, aspects include the electronic device 300 being integrated intoan on-board system of the vehicle. In various aspects, any portion ofprocessing performed via server 200 may be performed via the electronicdevice 300.

In certain aspects, the electronic device 300 may include a processor372 and a memory 378. The memory 378 may store an operating system 379and a risk assessment application 380. For example, memory 378 mayrepresent a tangible, non-transitory computer-readable medium, with eachof the operating system 379 and the risk assessment application 380including instructions executable by one or more processors (e.g.,processor 372) that, when executed by the one or more processors, causethe one or more processors to perform various acts as described herein.The memory 378 may include one or more forms of volatile and/ornon-volatile, fixed and/or removable memory, such as read-only memory(ROM), electronic programmable read-only memory (EPROM), random accessmemory (RAM), erasable electronic programmable read-only memory(EEPROM), and/or other hard drives, flash memory, MicroSD cards, andothers.

Furthermore, a computer program product in accordance with an aspect mayinclude a computer usable storage medium (e.g., standard random accessmemory (RAM), an optical disc, a universal serial bus (USB) drive, orthe like) having computer-readable program code embodied therein,wherein the computer-readable program code may be adapted to be executedby the processor 372 (e.g., working in connection with the operatingsystem 379) to facilitate the functions as described herein. In thisregard, the program code may be implemented In any desired language, andmay be implemented as machine code, assembly code, byte code,interpretable source code or the like (e.g., via C, C++, Java,Actionscript, Objective-C, Javascript, CSS, XML). In some embodiments,the computer program product may be part of a cloud network ofresources.

For example, the operating system 379 may represent an initial operatingsystem utilized by the electronic device 300. That is, if the electronicdevice 300 is implemented as a smartphone, then operating system 379 mayinclude one or more files, applications, code, etc., to facilitate userinteraction with and operation of the electronic device 300.

The risk assessment application 380 may include an application that isdownloaded to or otherwise installed onto the electronic device 300. Invarious aspects, the risk assessment application 380 may collect andtransmit telematics data and/or other types of data in the backgroundand/or while an operator is driving a vehicle via communication module377. For example, the risk assessment application 380 may monitor sensordata collected via the sensor array 384 and transmit this data to aserver (e.g., server 200), as further discussed below. The riskassessment application 380 may also monitor or otherwise collect othertypes of data, which may be transmitted with or separate from the sensordata transmissions such as time when sensor data was collected, weatherconditions (e.g., received via external communications), dataidentifying the vehicle operator, etc. The data transmitted by theelectronic device 300 in this manner, which may include sensor data andother types of data (e.g., geographic location data), may collectivelybe referred to herein as “telematics data.”

Moreover, as used herein, the term “telematics data” may refer to anysuitable type of data that may be used to identify a particular device,a particular driver, driving behavior or habits, road conditions,vehicle locations, users, a vehicle's movement while being driven, etc.,regardless of the particular component or source that generates thetelematics data. For example, telematics data may include theaforementioned sensor metrics generated by one or more components of theelectronic device 300, such as sensor metrics and/or geographic locationdata generated by measured by the sensor array 384. To provide anotherexample, the telematics data may include information generated by one ormore sensors, controllers, or other suitable components of a particularvehicle (e.g., vehicles 120, 130, and/or 140, as discussed above withreference to FIG. 1). To provide yet another example, the telematicsdata may include information generated by one or more sensors or portionof a smart infrastructure.

To provide an illustrative example, the telematics data may include,regardless of the device generating it, sensor metrics or otherinformation indicating changes in a vehicle's acceleration, braking,cornering, and/or velocity over time, which may include a timestampassociated with the sampled telematics data to allow each sampled datapoint to be associated with a specific time, thereby facilitatingtracking changes in the telematics data over time. To provide yetanother example, the telematics data may include sensor metrics or otherinformation related to accelerometer sensor measurements, gyroscopesensor measurements, compass heading measurements, etc. To providefurther examples, the telematics data may include information indicativeof changes in the geographic location of a particular electronic deviceand/or vehicle, which may likewise be correlated to a time stamp toidentify the movement of a vehicle over time, and thus track itsvelocity and/or route over time.

Still further, the telematics data may include information indicative ofa usage of an electronic device (e.g., a log indicating when the userwas texting or talking on the phone while driving), and/or a batterylevel associated with the first mobile computing device. To provide evenmore examples, the telematics data may include unique informationidentifying a particular user, vehicle, or smart infrastructurecomponent. The telematics data may also include data identifying certainweather conditions, which may be measured by a particular device orretrieved from a separate data source via data communications by thatdevice and included in a subsequent telematics data transmission. Thislist is not meant to be exhaustive or limiting, and it will beunderstood that other types of information may be included in thetelematics data transmission not listed here in accordance with theaspects described herein without departing from the spirit and scope ofthe present disclosure.

The electronic device 300 may further include a communication module 377configured to communicate data via one or more networks 320. Accordingto some embodiments, the communication module 377 may include one ormore transceivers (e.g., WWAN, WLAN, and/or WPAN transceivers)functioning in accordance with IEEE standards, 3GPP standards, or otherstandards, and configured to receive and transmit data via one or moreexternal ports 376. Further, the communication module 377 may include ashort-range network component (e.g., an RFID reader) configured forshort-range network communications. For example, the communicationmodule 377 may transmit telematics data to one or more other devices(e.g., sever 200) as discussed above. To provide another example, thecommunication module 377 may receive data and/or notifications fromother devices (e.g., server 200) regarding the insured individual'scurrent risk assessment, premium, or updated thereof, which may then bedisplayed via display screen 382.

The electronic device 300 may further include a sensor array 384. Theprocessor 372 and the risk assessment application 380 may be configuredto interface with the sensor array 384 to retrieve and process thecorresponding sensor data. The sensor array 384 may include one or moresensors configured to collect various types of sensor data, such asvelocity data, for example. In various aspects, the sensor array 384 mayinclude one or more cameras, accelerometers, gyroscopes, velocitysensors, magnetometers, barometers, thermometers, proximity sensors,light sensors, Hall Effect sensors, etc. In aspects in which the sensorarray 384 includes one or more accelerometers, the sensor array 384 maybe configured to measure and/or collect accelerometer values utilizingan X-axis, Y-axis, and Z-axis accelerometer. In accordance with suchaspects, the sensor array 384 may measure sensor metric values as athree-dimensional accelerometer vector that represents the movement ofthe electronic device 300 in three dimensional space by combining theoutputs of the X-axis, Y-axis, and Z-axis accelerometers using anysuitable techniques.

In one aspect, the accelerometer movement may then be analyzed (eitherlocally via electronic device 300 or via a server such as server 200) todetermine the velocity of the electronic device 300, and thus thevelocity of the vehicle in which the electronic device 300 is located.Aspects may also include the sensor array 384 directly measuring thevelocity of the electronic device 300 via any suitable sensor. In anyevent, the sensor array 384 may facilitate measuring the velocity of theelectronic device 300 over time in accordance with any suitable samplingperiod, such as continuously or periodically, for example. Thus, thetelematics data transmitted via the electronic device 300 may include anindication of a tracked velocity and direction of the vehicle in whichthe electronic device 300 is located over time.

In one aspect, the sensor array 384 may additionally include a globalnavigation satellite system (GNSS) configured to determine thegeographic location of electronic device 300. In accordance with suchaspects, the global navigation satellite system may generate geographiclocation data utilizing any suitable global positioning techniques. Forexample, the GNSS may communicate with one or more satellites and/orwireless transmitters to determine a location of the electronic device300. The GNSS may use “Assisted Global Positioning System” (A-GPS),satellite GPS, or any other suitable global positioning protocol (e.g.,the GLONASS system operated by the Russian government, the Galileosystem operated by the European Union, etc.) to determine a geographiclocation of the electronic device 300. Thus, the telematics datatransmitted by the electronic device 300 may additionally includegeographic location data.

Some aspects may include the geographic location data being analyzed(either locally via electronic device 300 or via a server such as server200) to determine the location of the electronic device at differenttimes, which may be correlated to other data included in the telematicsdata, such as sensor data indicating the velocity of the electronicdevice 300. Some aspects may also include the geographic location databeing analyzed (either locally via electronic device 300 or via a serversuch as server 200) to track the velocity of a vehicle in which theelectronic device 300 is located by calculating changes in the vehicle'sposition over time based upon the geographic location data.

The electronic device 300 may further include a user interface 381configured to present information to a user and/or to receive inputsfrom the user. As shown in FIG. 3, the user interface 381 may include adisplay screen 382 and I/O components 383 (e.g., ports, capacitive orresistive touch sensitive input panels, keys, buttons, lights, LEDs,speakers, microphones). According to some embodiments, the user mayaccess the electronic device 300 via the user interface 381 to reviewinformation and/or perform other functions.

Exemplary Vehicle Environment

FIG. 4A illustrates an exemplary scenario 400 depicting a set ofvehicles in operation on roadways 410 and 415. The scenario 400 mayinclude a target vehicle 430 travelling on a roadway 410. Again, thetarget vehicle 430 may be operated by an individual with an automobileinsurance policy that has a premium based upon an automobile insurancerisk assessment rating of the individual. Additionally, although notshown in FIG. 4A, there may be an electronic device (e.g., theelectronic device 125, 135, and/or 145 as discussed with respect to FIG.1 or the electronic device 300 as discussed with respect to FIG. 3)associated with the individual and/or the target vehicle 430. Further,FIG. 4A illustrates a geofence 440, which represents a distance having apredetermined radius surrounding the target vehicle 430. The geofence440 may be defined, for example, as a set of geographic coordinates. Thegeofence 440 will be discussed in more detail below with respect to FIG.4B.

In addition to the roadway 410, there is another roadway 415 that passesunderneath roadway 410. Both roadways 410 and 415 are two-way roadwaysin which vehicles may travel in either direction along the roadway. Acompass 420 indicates the directions of the roadways 410 and 415. Basedupon the direction of north (“N”) on the compass 420, roadway 410 isaligned substantially in the east/west direction and roadway 415 isaligned substantially in the southwest/northeast direction. The targetvehicle 430 is traveling in an eastbound direction along roadway 410. Invarious aspects, scenario 400 may include more or fewer roadways thanthe two roadways 410 and 415 as shown in FIG. 4A, and each roadway maybe aligned in any suitable direction.

As illustrated in the scenario 400 of FIG. 4A, in addition to the targetvehicle 430, there may be several other vehicles (i.e., other than thetarget vehicle 430) traveling in either direction on both roadway 410and 415. The other vehicles on roadways 410 and 415 may each betravelling at different velocities and may be travelling in differentdirections than one another. Additionally, although not shown in FIG.4A, other conditions may be present such as road constructions andweather conditions (e.g., rain, snow, fog, etc.). Some conditions, suchas the weather for example, will affect each of the vehicles regardlessof their direction of travel and regardless of the particular road uponwhich they are driving. Therefore, if the predetermined thresholdassociated with the geofenced area 440 is relatively small (e.g., a mileor two), it can be assumed that each of the vehicles is likelyexperiencing these same conditions. However, other conditions, such asroad construction, may be specific to not only a particular road, but toa particular direction of travel along that road. Thus, certain aspectsmay include identifying other vehicles based upon a number of factors toidentify those vehicles that are driving in similar conditions as thetarget vehicle 430. These factors are further discussed below.

FIG. 4B illustrates an example scenario 450 that represents a portion ofthe scenario 400 with respect to FIG. 4A. A compass 420 is depicted inthe scenario 450 and the compass 420 is oriented the same as the compass420 with respect to FIG. 4A. The scenario 450 of FIG. 4B also shows thetarget vehicle 430 from FIG. 4A and the geofence 440 surrounding it.However, the scenario 450 indicates the result of filtering out othervehicles that are not experiencing the same driving conditions as thetarget vehicle 430. In particular, the scenario 450 illustrates onlythose other vehicles that satisfy the conditions of (1) being inside thegeofence 440, and (2) traveling in the same direction as the targetvehicle 430 (and thus being on the same roadway).

Thus, the perimeter of the geofence 440 may be used as a predeterminedthreshold distance condition from the target vehicle 430. In one aspect,only the telematics data associated with other vehicles within thisgeofence 440 are initially selected for an average velocity calculation.In the example shown in FIG. 4B, the other conditions specified directlyabove are also used to determine the set of telematics data associatedwith other vehicles. However, certain aspects include using any suitablenumber and type of conditions to identify the set of other vehiclesexperiencing similar driving conditions as target vehicle 430. Forexample, aspects include only relying on geofence 440 and not includingthe vehicle's direction of travel as a condition. Such aspects may beparticular useful, for example, when the target vehicle 430 is in arural area or a less populous one. In some aspects, the number and/ortype of conditions used to identify the set of vehicles experiencingsimilar driving conditions as the target vehicle 430 may by dynamicallyupdated based upon the target vehicle's location, for example.

Additionally or alternatively, aspects include the radius and/or shapeof the geofence 440 being determined based upon any suitable numberand/or type of conditions such as the type of roadway (e.g., sidestreet, highway, etc.), the geographic location of the target vehicle430, the velocity of the target vehicle 430, current road conditions,weather conditions, etc. For example, the geofence 440 may initially bea circle having a specific radius in less densely populated areas, butchange to a geofence that has a smaller radius or matches the curvatureof road 410 when the target vehicle 430 approaches a more urbanenvironment.

Again, as depicted in the scenario 450 of FIG. 4B, only vehiclestraveling on the roadway 410 in the same direction as the target vehicle430 within the geofence 440 are shown. Thus, to calculate an averagevelocity of other vehicles experiencing similar driving conditions asthe target vehicle 430, only telematics data from the other vehicles asshown in scenario 450 are considered.

In one aspect, the vehicles depicted in FIGS. 4A and 4B may indicate areal-time representation of vehicles that are being operated bydifferent drivers on the roadways 410 and 415 within the vicinity of thetarget vehicle 430. In particular, as shown in scenario 450 of FIG. 4B,the vehicles within the geofence 440 that are traveling in the samedirection as the target vehicle 430 on roadway 410 may representvehicles that are currently traveling on roadway 410 at the same time astarget vehicle 430 is traveling on roadway 410. Because the vehicles inthis embodiment are present on roadway 410 at the same time as thetarget vehicle 430, all of the vehicles are experiencing the same roadconditions, weather conditions, etc. as the target vehicle 430.

In other aspects, the vehicles depicted in FIGS. 4A and 4B may indicatea historical representation of other vehicles, which were previouslyoperated by drivers on the roadways 410 and 415 within the vicinity ofthe target vehicle 430. In particular, as shown in scenario 450 of FIG.4B, the vehicles within the geofence 440 that are traveling in the samedirection as the target vehicle 430 on roadway 410 may representvehicles that have previously traveled along roadway 410 within aparticular time period (e.g., a threshold window of time) at a time ofday that matches when the target vehicle 430 is traveling on roadway410. Such aspects may be particularly useful to calculate an averagevelocity of a larger group of vehicles over a larger period of time(e.g., a month, a year, etc.) to determine a historical average velocityof vehicles are certain times throughout the day. In doing so, thevelocity of the target vehicle 430 may be compared at any given time tothe historical average velocity of the other vehicles at the same timeand place. Alternatively, the velocity of target vehicle 430 may betracked over several days at the same time, which is then averaged andthen compared to the historical average velocity of the other vehiclesat the same time and place.

Exemplary Telematics Data

The tables shown in FIGS. 5A-5B and FIGS. 6A-6C and discussed belowinclude several different types of data. In some aspects, this data mayrepresent portions of telematics data that is transmitted by severalelectronic devices (e.g., electronic devices 125, 135, and 145, as shownin FIG. 1) and received and processed by a computing device (e.g.,server 200, as shown in FIG. 2). In various aspects, some (or all) ofthe telematics data shown in FIGS. 5A-5B and FIGS. 6A-6C and discussedbelow may be received from telematics data transmitted via an electronicdevice running a risk assessment application. For example, electronicdevice 300 may transmit telematics data as a result of processor 372executing instructions stored in risk assessment application 380, asshown and discussed above with reference to FIG. 3.

However, aspects also include some (or all) of the telematics data shownin FIGS. 5A-5B and FIGS. 6A-6C and discussed below being collected viaother applications or data sources. For example, third partyapplications (e.g., Waze and Google Maps) may be installed on computingdevices (e.g., smartphones), which may be located in respectivevehicles, thereby enabling each respective computing device to generate,locally store, report, transmit, and/or otherwise provide telematicsdata or other data from which the telematics data as discussed hereinmay be derived. In some aspects, the third party applications may alsobe executed on, for example, the electronic devices 125, 135, and/or145, whereas other aspects include the third party applications beingexecuted on other computing devices not shown in FIG. 1 for purposes ofbrevity. Thus, in various aspects, the telematics data may be procuredfrom any suitable combination of the electronic devices 125, 135, and/or145, vehicles 120, 130, and 140, etc. (e.g., as discussed above withrespect to the execution of risk assessment application 380) and/or viathird party applications.

In some aspects, the data generated by such third party applications maybe part of a “crowdsourcing” or aggregate reporting utility thatfunctions to determine certain types of data, which is then reported toone or more servers used in accordance with the third party applicationand/or made available to other computing devices running the third partyapplication. In accordance with such aspects, this reported data mayinclude any suitable type of data that may be used in accordance withthe various aspects described herein. For example, the reported data mayinclude real time vehicle speed (i.e., the vehicle in which eachrespective computing device is located), weather information at eachcomputing device location, location data, information regarding roadconditions at each computing device location, traffic data, etc. Invarious aspects, the data reported by the third party applications maybe collected via one or more sensors incorporated as part of eachcomputing device and/or information that is manually identified and/orreported by a user.

In any event, the third party applications may be running on anysuitable number of computing devices (e.g., several hundred, thousand,million, etc.), which form a “pool” of devices and reported data. Thispool of data may then be procured by a remote server (e.g., server 200)in a similar manner as the telematics data discussed herein with respectto electronic devices 125, 135, and 145, vehicles 120, 130, and 140,etc. For example, server 200 may be configured to communicate (e.g., vianetwork 232) with a third party server that supports the third partyapplications and/or stores data reported by the computing devicesexecuting the third party applications. To provide another example,server 200 may be configured to communicate with the computing devicesexecuting the third party applications to store the reported data todatabase 225 or another suitable location, which may then be accessed asneeded for the various calculations as discussed herein. For instance,the server 200 may implement communications via an applicationprogramming interface (API) services call to the computing devicesexecuting the third party application.

In the case when the computing device receiving and processing this datais implemented as the server 200, the filtering actions and othercalculations discussed with reference to FIGS. 5A-5B and FIGS. 6A-6C maybe performed via execution of instructions via controller 220 and/orprocessor 240. For example, the logs shown in FIGS. 5A-5B and FIGS.6A-6C may represent data that is identified, assembled, and/or filteredas a result of the execution of instructions stored in log generationapplication 261 via processor 240. Additionally, the average velocitycalculations shown in FIGS. 5A-5B and FIGS. 6A-6C may be the result ofthe execution of instructions stored in vehicle relative speedapplication 262 via processor 240.

Exemplary Real-Time Telematics Data

FIGS. 5A and 5B each depict an exemplary table of real-time telematicsdata for a group of vehicles, in accordance with aspects of the presenttechnology. FIGS. 5A and 5B illustrate tables 500 and 510, respectively,which correspond to real-time telematics data collected from severalelectronic devices, each being located in or otherwise associated with arespective vehicle. For example, table 500 may represent telematics datacollected from electronic devices associated with a target vehicle 430and several other vehicles traveling within a geofence 440 having athreshold radius of 0.25 miles, as discussed above with respect to FIGS.4A and 4B. Because the telematics data shown in FIGS. 5A and 5B isreal-time telematics data, the date and time for each telematics dataentry (i.e., each row) is the same as the target vehicle (i.e., 5:02PM).

As shown in tables 500 and 510, each vehicle may be identified by itsuniquely identified respective electronic device ID. This electronicdevice ID may include, for example, any suitable information received inthe telematics data transmission that uniquely identifies eachindividual electronic device. This may include, for example, a mediaaccess controller (MAC) address, an International Mobile EquipmentIdentity (IMEI) number, a phone number, etc. In one aspect, the targetvehicle's telematics data may include a unique electronic device ID,which may be used to identify the insured customer. Additionally oralternatively, the target vehicle's telematics data may provideinformation that directly identifies the insured customer such as alogon ID, for example.

In any event, aspects include the real-time telematics data beingcollected in a manner such that each vehicle may be uniquely identifiedand correlated to its own set of telematics data when stored in adatabase (such as the database 160 as discussed with respect to FIG. 1and/or the database 225 as discussed with respect to FIG. 2).Additionally, in various aspects, the real-time telematics data for eachvehicle may be accessed by an electronic device (such as the electronicdevices 125, 135, and 145 as discussed with respect to FIG. 1 and/or theelectronic device 300 as discussed with respect to FIG. 3) and/or aremote server (such as the remote server 150 as discussed with respectto FIG. 1 and/or the remote server 210 as discussed with respect to FIG.2).

Further, each vehicle's real-time telematics data entry in tables 500and 510 has a specific velocity (in mph) and distance from the targetvehicle (in miles) associated with the vehicle on Mar. 22, 2017 at 5:02PM. The distance entry is illustrated for ease of explanation, and it isto be understood that the data represented by this entry may becalculated in any suitable manner to identify vehicles within thegeofence 440. For example, mathematical calculations may be performed tocalculate a difference between the geographic coordinates of eachvehicle (which may be included as part of the telematics data) comparedto the target vehicle.

FIG. 5A depicts a table 500 of real-time telematics data filtered by thegeofence 440. In other words, table 500 indicates telematics dataentries for a target vehicle (e.g., target vehicle 430 on roadway 410,as discussed with respect to FIGS. 4A-4B) and other vehicles travelingwithin the geofence 440 at the same time. As indicated at the top ofFIG. 5A, the target vehicle is traveling east. Because the real-timetelematics data shown in table 500 is not filtered by direction, thereal-time telematics data includes vehicles traveling in any directionwithin the geofence 440. However, to calculate an accurate averagevelocity to determine the average velocity differential for the targetvehicle, certain aspects include further filtering the real-timetelematics data by direction, such that only real-time telematics datafor the plurality of other vehicles traveling in the same direction asthe target vehicle is used for calculating the average velocitydifferential.

In other words, the real-time telematics data for vehicles that are nottraveling in the same direction as the target vehicle are not relevantfor the calculation of the average velocity. Therefore, table 510 fromFIG. 5B may only include vehicle entries for vehicles that are travelingthe same direction as the target vehicle (i.e., east), and are thustraveling on the same roadway as the target vehicle. To this end, FIG.5B depicts a table 510 of real-time telematics data that is filtered bydirection, and includes telematics data entries for the target vehicleand the other vehicles traveling within the geofence 440. As shown intable 510, the direction-filtered real-time telematics data may onlyinclude entries for other vehicles traveling east, which are alsolocated in the geofence 440. Thus, only the real-time telematics datafor vehicles located within geofence 440 and traveling in the samedirection as the target vehicle are used to calculate the averagevelocity, and subsequently, the average velocity differential for thetarget vehicle compared to these other vehicles.

In one aspect, the velocity data from table 510 for the other vehicles(i.e., not including the target vehicle) that are traveling in the samedirection as the target vehicle (i.e., traveling east) may be averagedto determine an average velocity. Based upon the average velocity, anaverage velocity differential may then be calculated by subtracting thisaverage velocity from the velocity of the target vehicle at the sametime (i.e., 5:02 PM). A negative average velocity differential indicatesthat the target vehicle is going slower than the average velocity of theother vehicles that are traveling within the geofence 440 and in thesame direction as the target vehicle.

On the other hand, a positive average velocity differential indicatesthat the target vehicle is traveling faster than the average velocity ofthe other vehicles that are traveling within the geofence 440 and in thesame direction as the target vehicle. As shown in table 510, the averagevelocity of the other vehicles (not including the target vehicle) is34.78 mph and the average velocity differential between the targetvehicle and the plurality of other vehicles is −9.78 mph (i.e., thetarget vehicle is going 9.78 mph slower than the average velocity of theother vehicles).

Exemplary Historical Telematics Data

FIGS. 6A, 6B, and 6C each depict an exemplary table of historicaltelematics data for a group of vehicles, in accordance with certainaspects of the present technology. FIGS. 6A, 6B, and 6C depict exemplarytables 600, 610, and 620, respectively, of historical telematics datafor a target vehicle (e.g., the target vehicle 430 discussed withrespect to FIGS. 4A and 4B) and other vehicles that have previouslytraveled within the geofence 440. Since the telematics data shown intables 600, 610, and 620 is historical telematics data, the date foreach entry varies. However, the telematics data shown in tables 600,610, and 620 has been filtered initially by day of the week, such thateach telematics data entry corresponds to the same day as the targetvehicle, such as Thursday with respect to tables 600, 610, and 620.

Additionally, because the telematics data shown in tables 600, 610, and620 is historical telematics data, the time for each vehicle entry ofeach table may vary slightly. Thus, the telematics data shown in tables600, 610, and 620 has also been filtered based upon a threshold timeperiod (i.e., a threshold window of time before and after the time thatthe target vehicle is traveling on the roadway), such as 5 minutes withrespect to tables 600, 610, and 620. Further, for each telematics dataentry in tables 600, 610, and 620, weather conditions experienced byeach respective vehicle at the time the telematics data was received (orgenerated) is also indicated.

Similar to the tables 500 and 510, the tables 600, 610, and 620 may alsoinclude a unique electronic device ID. In various aspects, thehistorical telematics data for each vehicle may be collected and storedin a database (such as the database 160 as discussed with respect toFIG. 1 and/or the data storage device 225 as discussed with respect toFIG. 2) and the unique electronic device ID may be used to correlateeach particular vehicle to its telematics data. Additionally, in someembodiments, the historical telematics data may be accessed by anelectronic device (such as the electronic devices 125, 135, and 145 asdiscussed with respect to FIG. 1 and/or the electronic device 300 asdiscussed with respect to FIG. 3) and/or a remote server (such as theserver 150 as discussed with respect to FIG. 1 and/or the server 200 asdiscussed with respect to FIG. 2). Further, each historical telematicsdata entry has a velocity (in mph) and distance from the target vehicle(in miles).

FIG. 6A depicts a table 600 of historical telematics data for the targetvehicle and other vehicles that is filtered by (1) vehicles that havepreviously traveled within geofence 440, (2) on the same day of theweek, and (3) within a 5 minute threshold time period (before and after)the time of the target vehicle. As indicated at the top of FIG. 6A, thetarget vehicle is traveling north during rain. Because the historicaltelematics data shown in table 600 is not filtered based upon weatherconditions or direction, the historical telematics data in table 600represents historical telematics data for other vehicles that havepreviously traveled in any direction and during any weather conditionswithin the geofence 440.

In various aspects, to calculate an accurate average velocity todetermine the average velocity differential for the target vehicle, someaspects may include further filtering the historical telematics data bydirection and weather condition. As a result, only historical telematicsdata for vehicles that have previously traveled on the same roadway, inthe same direction, in the same weather conditions, and during the sametime period as the target vehicle are used for calculating the averagevelocity.

FIG. 6B depicts a table 610 of historical telematics data for the targetvehicle and the other vehicles traveling within the geofence 440filtered by direction. Since the historical telematics data listed intables 600 and 610 indicates that the target vehicle is traveling north,the historical telematics data for the other vehicles, once filtered,only includes vehicles also traveling north. As a result, only thehistorical telematics data from vehicles that have previously traveledin the same direction as the target vehicle are used to calculate theaverage velocity, and subsequently, the average velocity differentialfor the target vehicle compared to these other vehicles. The historicaltelematics data for the other vehicles that did not previously travel inthe same direction as the target vehicle is not relevant for thecalculation of the average velocity and is filtered out of table 600from FIG. 6A. Therefore, table 610 from FIG. 6B only includes vehicleentries for the plurality of other vehicles that have previouslytraveled in the same direction as the target vehicle (i.e., north).

FIG. 6C depicts another table 620 of historical telematics data for thetarget vehicle and the other vehicles that have previously travelednorth within the geofence 440 filtered by direction and weather. Thehistorical telematics data listed in tables 600, 610, and 620 indicatesthat the target vehicle is traveling north when it is raining. Aspectsinclude further filtering the telematics data by weather conditions.Therefore, table 620 of FIG. 6C only includes historical telematics datafor other vehicles that have (1) previously traveled north at the sametime as the target vehicle (i.e., within a threshold time period of +/−5minutes), and (2) have done so when it was raining. As a result, onlythe historical telematics data for other vehicles that have previouslytraveled within the geofence 440, traveled in the same direction as thetarget vehicle, and experienced the same driving conditions as thetarget vehicle are used to calculate the average velocity, andsubsequently, the average velocity differential for the target vehiclecompared to these other vehicles.

Again, a positive and negative average velocity differential indicatesthat the target vehicle is traveling faster or slower, respectively,than the average velocity of the other vehicles traveling within thegeofence 440, during the same time, in the same direction, and duringthe same weather conditions as the target vehicle. As shown in table620, the average velocity of the vehicles (not including the targetvehicle) is 42.4 mph and the average velocity differential between thetarget vehicle and the plurality of other vehicles is +12.6 mph (i.e.,the target vehicle is going 12.6 mph faster than the average velocity ofthe other vehicles).

In various aspects, historical telematics data may be accessed whenthere is no real-time telematics data or there is a limited amount ofreal-time telematics data that needs to be supplemented with historicaltelematics data to have a sufficient sample size to performcalculations. For example, there may not be a sufficient sample size ofreal-time telematics data for a target vehicle traveling on a particularportion of a rural roadway. However, by supplementing any real-timetelematics data with historical telematics data from other vehicles thatwere previously driven on that particular part of the rural roadway, asufficient sample size of telematics data may be obtained.

Historical telematics data may include telematics data for a pluralityof other vehicles that were previously operated by a plurality ofdrivers within a certain threshold distance of the target vehicleregardless of what roadway the vehicles had previously traveled on.Moreover, in some embodiments, the set of historical telematics data mayinclude data indicative of weather conditions experienced by each of theplurality of other vehicles when the second set of telematics data wasgenerated. Further, the historical telematics data may require filteringin order to narrow down the telematics data to telematics data thatrepresents only vehicles that are traveling on the same roadway, in thesame direction, within a threshold distance and a threshold time period,and in the same weather conditions that the target vehicle is travelingin. The remote server and/or electronic device may perform the functionof filtering the historical telematics data.

Exemplary Computer-Implemented Method for Assessing an AutomobileInsurance Risk Rating

FIG. 7 depicts an exemplary flow diagram associated with assessing anautomobile insurance risk rating, in accordance with certain aspects ofthe present technology. FIG. 7 illustrates an exemplarycomputer-implemented method 700 for using a vehicle's relative speed todetermine an automobile insurance risk assessment rating for anindividual. In various aspects, one or more portions of the method 700(or the entire method 700) may be facilitated by one or more processorsof a suitable device (such as the remote server 150 as discussed withrespect to FIG. 1, the remote server 200 as discussed with respect toFIG. 2, the electronic devices 125, 135, and 145 as discussed withrespect to FIG. 1, and/or the electronic device 300 as discussed withrespect to FIG. 3). The remote server may support execution of adedicated application that may facilitate the functionalities of themethod 700. For example, method 700 may be realized via execution of theautomobile insurance RAR application 263 via controller 220 and/orprocessor 240, as discussed above with reference to FIG. 2.

The method 700 may begin when the one or more processors receive a firstset of telematics data associated with a vehicle (such as the targetvehicle 430 discussed with respect to FIGS. 4A and 4B) (block 705). Invarious aspects, the first set of telematics data may include geographiclocation data indicating a real-time geographic location of the targetvehicle. Using this geographic location data (or other sensor dataincluded in the telematics data transmission), a velocity and direction(such as the velocity and direction indicated in the tables 500, 510,600, 610, and 620 as discussed with respect to FIGS. 5A-5B and 6A-6C)for the target vehicle may be determined.

Additionally, aspects include the one or more processors recording atimestamp representing a time and date (such as the time and dateindicated in the tables 500, 510, 600, 610, and 620) associated withwhen the first set of telematics data was generated and/or received.Further, the telematics data may include data indicative of the weatherconditions (such as the weather conditions indicated in the tables 500,510, 600, 610, and 620) in which the target vehicle is traveling.Additionally or alternatively, the one or more processors may record thecurrent weather conditions associated with the location of the targetvehicle when the first set of telematics data was generated and/orreceived.

Method 700 may include one or more processors accessing a second set oftelematics data associated with other vehicles located within athreshold distance of the target vehicle (block 710). The second set oftelematics data may indicate a velocity of each of the other vehicleswithin a time period that is associated with when the first set oftelematics data was generated and/or received. In some embodiments, thetime period is a threshold window of time (i.e., threshold time period)with respect to the timestamp representing the time and date the firstset of telematics data was generated and/or received. In the case ofaccessing telematics data in real-time, the timestamp may be identical(or nearly identical) to the timestamp for the first set of telematicsdata, such as those shown in tables 500 and 510, for example.

For any historical telematics data included in the second set oftelematics data, the threshold time period may be, for example, a windowof time before and after the timestamp associated with the first set oftelematics data. For example, the threshold time period shown in FIGS.6A-6C is +/−5 minutes. Also for example, since the timestamp for thefirst set of telematics data associated with the target vehicle intables 600, 610, and 620 of FIGS. 6A-6C is Mar. 23, 2017 at 7:54 AM, thethreshold time period for the generation of the second set of telematicsdata (historical telematics data for FIGS. 6A-6C) is from 7:49 AM to7:59 AM on the same day, Mar. 23, 2017.

After accessing the second set of telematics data, method 700 mayinclude one or more processors averaging the velocity of each of theother vehicles to determine an average velocity (block 715). Again, invarious aspects, the second set of telematics data may includegeographic location data indicating a geographic location of each of theother vehicles, which may be used to calculate each vehicle's velocity.The one or more processors may determine the direction and velocity of avehicle based upon the change in each vehicle's geographic location overtime. By determining the direction of the other vehicles, the second setof telematics may be filtered by direction (such as the filteredtelematics data in tables 510 and 610 as discussed with respect to FIGS.5B and 6B, respectively), thereby eliminating irrelevant telematics datafrom the calculation of average velocity. After the second set oftelematics data is filtered, method 700 may include one or moreprocessors calculating the average velocity of the filtered telematicsdata (block 715).

After the average velocity of the vehicles from the completely filteredsecond set of telematics data have been calculated, method 700 mayinclude one or more processors calculating an average velocitydifferential based upon the difference between the average velocity(block 715) and the velocity of the target vehicle (block 720).

Based upon the calculated average velocity differential (block 720),method 700 may include one or more processors determining an automobileinsurance risk assessment rating (block 725). In various aspects, theone or more processors may calculate the automobile insurance riskassessment rating by compensating for weather conditions and roadconditions, because driving behavior may be affected by such conditions.For example, the automobile insurance risk assessment rating mayrepresent a numeric score that reflects higher risks with increasingnumeric values.

The automobile insurance risk assessment rating is an indication of howsafe (or unsafe) an individual's driving behavior is when operating avehicle. The safer an individual's driving behavior is when operating avehicle, the lower the individual's automobile insurance risk assessmentrating will be. As one example, the automobile insurance risk assessmentrating may be a numerical value between 0 and 100. For example, anindividual with an automobile insurance risk assessment rating of 0 mayexhibit very safe driving behavior, an individual with an automobileinsurance risk assessment rating of 50 may exhibit average drivingbehavior, and an individual with an automobile insurance risk assessmentrating of 100 may exhibit very unsafe driving behavior.

In various aspects, an insured individual may begin an automobileinsurance policy with a default automobile insurance risk assessmentrating of 50. Based upon the insured individual's subsequent drivingbehavior, the insured individual's automobile insurance risk assessmentrating may increase or decrease. For example, if the insuredindividual's relative speed (i.e., average velocity differential) iswithin a certain threshold range (e.g., a threshold mph range or athreshold percentage range) of the average velocity of the othervehicles in the vicinity, the insured individual may be exhibiting saferthan average driving behavior, thereby decreasing the insuredindividual's automobile risk assessment rating. Thus, if the insuredindividual's automobile insurance risk assessment rating is 50 and therelative speed of the insured individual's vehicle is 3 mph faster thanthe average velocity of the other vehicle in the vicinity, and thethreshold mph range is ±5 mph of the average velocity of the othervehicles in the vicinity, then the insured individual may be exhibitingsafer than average driving behavior. As a result, the insuredindividual's automobile insurance risk assessment rating may decreasefrom 50 to 40.

For another example, if the relative speed of the vehicle of the insuredindividual just mentioned in the previous paragraph is above thethreshold range of the average velocity of the other vehicles in thevicinity, the insured individual may be exhibiting driving behavior thatis unsafe or riskier when compared to average driving behavior.Therefore, the insured individual's automobile insurance risk assessmentrating may increase. Thus, if the insured individual's automobileinsurance risk assessment rating is 50 and the relative speed of theinsured individual's vehicle is 12 mph higher than the average velocityof the other vehicles in the vicinity (with the threshold mph rangebeing ±5 mph), then the insured individual may be exhibiting drivingbehavior that is unsafe and the insured individual's automobileinsurance risk assessment rating may increase from 50 to 70. The insuredindividual's automobile insurance risk assessment rating may increase by20 points because the relative speed of the vehicle that the insuredindividual is driving is over 10 mph than the average speed of the othervehicles in the vicinity, and has repeatedly demonstrated this drivingbehavior, as further discussed below.

In other aspects, other conditions may also affect an individual'sautomobile risk assessment rating. Conditions such as weather, roadconditions, construction, etc., may adversely affect an individual'sdriving behavior, and thus, may have an impact on an individual'sautomobile risk assessment rating. For example, the historicaltelematics data 600, 610, and 620 from FIGS. 6A-6C indicate that theindividual is driving the target vehicle when it is raining.Additionally, the historical telematics data 620 indicates that therelative speed of the target vehicle is 12.6 mph faster than the averagevelocity of the other vehicles in the vicinity. If the threshold mphrange is ±5 mph, not only is the individual traveling over twice as fastas the average velocity of the other vehicles in the vicinity, but theindividual is doing so while it is raining. Therefore, if the individualinitially had an automobile insurance risk assessment rating of 50, itmay now increase by 20 points because individual driving at a very highrelative speed and another 10 points because the individual is doing soin the rain. As a result, the individual's automobile insurance riskassessment rating may increase from 50 to 80.

In various aspects, method 700 may include one or more processorscalculating an automobile insurance premium based upon the calculatedautomobile insurance risk assessment rating (block 730). In variousaspects, the insured individual's automobile insurance risk assessmentrating and the resulting adjustments to the insured individual's premiumas a result of this rating may be related by any suitableproportionality, function, of dependency. For example, the automobileinsurance risk assessment rating and the corresponding automobileinsurance premium may be directly proportional. In other words, a higherautomobile insurance risk assessment rating generates a higherautomobile insurance premium, and conversely, a lower automobileinsurance risk assessment rating generates a lower automobile insurancepremium.

As mentioned above, an insured individual may begin an automobileinsurance policy with a default automobile insurance risk assessmentrating of 50. Because of this, the insured individual's automobileinsurance premium may also default to a certain amount, for example$300. In various aspects, a change in the insured individual'sautomobile risk assessment rating may result in a percentage change ofthe insured individual's automobile insurance premium. For example, forevery 10 points increase or decrease of an insured individual'sautomobile insurance risk assessment rating, the insured individual'sautomobile insurance premium may respectively increase or decrease by10%. Therefore, if an insured individual's automobile insurance riskassessment rating decreases from 50 to 30, the insured individual'sautomobile insurance premium may decrease by 20% to $240. On the otherhand, if an insured individual's automobile insurance risk assessmentrating increases from 50 to 80, the insured individual's automobilepremium may increase by 30% to $390.

For example, the target vehicle associated with the real-time telematicsdata of tables 500 and 510 from FIGS. 5A and 5B, respectively, indicatesthat the target vehicle's relative speed is 9.78 mph slower (i.e., theaverage velocity differential is −9.78 mph) than the average velocity ofthe other vehicles in the vicinity. In this case, the target vehicle mayactually be creating dangerous conditions on the roadway because it isgoing so much slower than the average speed of the vehicles surroundingit (i.e., the target vehicle is going much slower than the speed oftraffic). Other vehicles may have to slam on their brakes whenapproaching the target vehicle and/or they may switch lanes to go aroundthe vehicle. This type of behavior may create dangerous drivingconditions in the vicinity of the target vehicle, which may increase thelikelihood of an accident or condition that may result in propertydamage, injury, and death. Therefore, the automobile insuranceassessment rating of the individual operating the target vehicle mayincrease because of the driving behavior exhibited by the individualwhile operating the target vehicle. Further, the driver's automobileinsurance premium may increase as a result of this increase to theautomobile insurance assessment rating.

As another example, the target vehicle associated with the historicaltelematics data of tables 600, 610, and 620 from FIGS. 6A-6C,respectively, indicates that the target vehicle's relative speed is 12.6mph faster (i.e., the average velocity differential is +12.6 mph) thanthe average velocity of the other vehicles. In this case, the targetvehicle is going much faster than the average speed of the othervehicles proximate to the target vehicle (i.e., the target vehicle isgoing much faster than the speed of traffic). As a result, the driver ofthe target vehicle may be creating dangerous road conditions on theroadway because it may be changing lanes frequently, cutting othervehicles off, etc., to achieve this. Additionally, it is raining whilethe target vehicle is on the roadway, and therefore there may be reducedvisibility, a slippery roadway, etc. in addition to thehigher-than-average speed of the target vehicle, creating an evengreater risk. Therefore, the automobile insurance assessment rating ofthe individual operating the target vehicle may also increase because ofthe driving behavior exhibited by the individual while operating thetarget vehicle. Again, the individual's automobile insurance premium mayincrease as a result of this increase to the individual's automobileinsurance assessment rating.

To prevent an automobile insurance risk assessment rating fromincreasing, and consequently preventing the associated automobileinsurance premium from increasing, it is preferable that a targetvehicle be operated close to the average calculated velocity of thevarious other vehicles (either in real-time or historically) asdiscussed herein with reference to tables 500, 510, 600, 610, and 620.Additionally, if an individual's automobile insurance risk assessmentrating is high to begin with, it may be decreased by continuouslyoperating the target vehicle closer to the calculated average velocityof the other vehicles (either in real-time or historically) over time.As the individual's automobile insurance risk assessment rating isdecreased, the individual's automobile insurance premium may likewisedecrease.

In various aspects, an individual's automobile insurance risk assessmentrating may increase or decrease based upon an analysis of the calculatedaverage velocity differential over time. In other words, the velocitydifferential discussed herein may be based upon several differentinstances for the purposes of assessing the driver's risk. For example,if a target vehicle's calculated average velocity differential atvarious times is greater than a certain threshold velocity for more thana threshold number of days within a month, a threshold number ofconsecutive days, a threshold number of times throughout a single day,etc., then the individual's automobile insurance risk assessment ratingmay increase accordingly. Furthermore, the opposite may be true when thetarget vehicle's calculated average velocity differential at variousdifferent times is within a threshold velocity window of the othervehicle's calculated average velocity for a threshold number of dayswithin a month, a threshold number of consecutive days, a thresholdnumber of times throughout a single day, etc.

Thus, in various aspects, the electronic device that determines theindividual's automobile insurance risk assessment rating (e.g., remoteserver 200) may transmit this information and/or an automobile insurancepremium to an electronic device associated with the target vehicleoperator (e.g., the electronic device 125, 135, and/or 145 with respectto FIG. 1 and/or the electronic device 300 with respect to FIG. 3) whois an insured driver.

Further, in various aspects, upon receiving information via thetransmission as noted directly above, the electronic device may providea set of recommendations to allow the insured driver to improve herautomobile insurance risk assessment rating, thus lowering herautomobile insurance premium. For example, the set of recommendationsmay be included as part of the information related to the individual'sautomobile insurance risk assessment rating and automobile insurancepremium that was transmitted from the remote server to the electronicdevice. The user interface of the electronic device may then displaythis information and/or one or more links to access this information forthe insured driver to review. The set of recommendations may include,for example, tips for driving in adverse weather conditions, specificlocations where bad driving behavior was exhibited by the individual,recommendations to mitigate identified driving behaviors that areexcessively high risk, etc. Additional details regarding thenotification and other information that may be presented to an insureddriver via her electronic device are further discussed below.

Exemplary Computer-Implemented Method for Assessing an AutomobileInsurance Risk Rating and Updating Insurance Data

FIG. 8 depicts an exemplary flow diagram associated with assessing anautomobile insurance risk rating, in accordance with aspects of thepresent technology. FIG. 8 illustrates an exemplary computer-implementedmethod 800 for updating insurance data associated with a target vehicleusing telematics data. In various aspects, one or more portions of themethod 800 (or the entire method 800) may be facilitated by one or moreprocessors of a suitable device (such as the remote server 150 asdiscussed with respect to FIG. 1, the remote server 200 as discussedwith respect to FIG. 2, the electronic devices 125, 135, and 145 asdiscussed with respect to FIG. 1, and/or the electronic device 300 asdiscussed with respect to FIG. 3). The remote server may supportexecution of a dedicated application that may facilitate thefunctionalities of the method 800. For example, method 800 may berealized via execution of the automobile insurance RAR application 263via controller 220 and/or processor 240, as discussed above withreference to FIG. 2.

The method 800 may begin when the one or more processors receivetelematics data associated from one or more vehicles (such as the targetvehicle 430 and other nearby vehicles as discussed with respect to FIGS.4A and 4B) (block 802). Again, in various aspects, the telematics datamay include any suitable type of data used to calculate an averagevelocity differential, among other information (block 802). Moreover,the telematics data may originate and/or be generated by different typesof components or devices, such as vehicles, smart infrastructurecomponents, dashboard plug-in devices, and/or mobile devices orelectronic devices, as discussed above with reference to FIG. 1. Forexample, the telematics data may be transmitted continuously orperiodically and include geographic location data indicating a real-timegeographic location of the target vehicle. Additionally, the telematicsdata may indicate the geographic location of other nearby vehicles (inreal-time or based upon stored historical telematics data) and/or sensormetrics used to identify each vehicle's acceleration, braking,cornering, velocity, heading, route, etc. (block 802).

The method 800 may include one or more processors determining an averagevelocity associated with a plurality of other vehicles (block 804).Again, these other vehicles may correspond to other vehicles proximateto a target vehicle (in real-time or based upon historical telematicsdata), that satisfy various conditions such that each of the othervehicles is experiencing similar driving conditions as the targetvehicle. These conditions may include, for example, distance, time ofday and/or week, weather conditions, direction, etc.

Method 800 may include one or more processors determining the averagevelocity of the other vehicles in any suitable manner based upon thetype of telematics data available (block 804). For example, method 800may include one or more processors using changes in geographic locationdata over time (or other sensor data included in the telematics datatransmission) to identify a velocity and direction of each of the othervehicles at various times (such as the velocity and direction indicatedin the tables 500, 510, 600, 610, and 620 as discussed with respect toFIGS. 5A-5B and 6A-6C). As examples, the velocity of other vehicles inthe vicinity of, or traveling in the same direction and along the samearea of road as, a target vehicle may be determined from (1) one or moresensors or processors mounted on the target vehicle itself, (2) one ormore sensors or processors mounted on the other vehicles (which may besmart or interconnected vehicles capable of wireless communication, andconfigured to transmit speed, heading or direction, route, and/orlocation information), and/or (3) one or more sensors or processorsmounted on, or associated with, smart infrastructure (such as smart roadsigns, smart mile markers, or smart toll booths). Once a velocity isdetermined for each of the other vehicles, method 800 may includeaveraging these velocities together to calculate an average velocityassociated with the other vehicles (block 804).

The method 800 may include one or more processors comparing the velocityof a target vehicle to the average velocity (block 804) associated withthe other vehicles (block 806). In some aspects, this may includecomparing a real-time velocity of the target vehicle to the real-timeaverage velocity associated with the other vehicles, as discusseddirectly above (block 806). In other aspects, this may include comparinga real-time or historical velocity of the target vehicle to thehistorical average velocity associated with the other vehicles, asdiscussed directly above (block 806). In any event, the result of thiscomparison may yield an average velocity differential between the targetvehicle and the other vehicles (block 806). This average velocitydifferential may be, for example, similar to the average velocitydifferential shown in FIGS. 5B and 6C, as discussed herein (block 806).

The method 800 may include one or more processors updating insurancedata associated with the target vehicle or a driver of the targetvehicle (block 808). This may include, for example, calculating a riskassessment rating for an insured driver associated with the targetvehicle, and updating various insurance-related information for theinsured driver based upon this and/or other calculations (block 808).

For example, method 800 may include periodically updating information onfile for an insured driver based upon changes to her risk assessmentrating (block 808). This may also include, for example updating otherinformation that is affected by the risk assessment rating (block 808).Some examples of other information that may be affected in this way mayinclude insurance premium pricing, qualifying (or no longer qualifying)for “safe driver” or other applicable discounts, terminating insurancecoverage, etc. (block 808). In various aspects, one or more portions ofmethod 800 (or the entire method 800) may be repeated (blocks 802, 804,806, and/or 808) continuously or periodically such that the insurancedata is updated over time. In other words, a user's risk assessmentrating may be updated over time based upon the driver's tracked velocitycompared to other similarly-situated drivers, such that transient orone-time measurements of excessive velocity do not result in thedriver's insurance information being unnecessarily updated. The methodmay include additional, less, or alternate actions, including thosediscussed elsewhere herein.

Exemplary User Interface

FIG. 9 depicts an exemplary user interface associated with displayingautomobile insurance risk assessment information, in accordance withaspects of the present technology. FIG. 9 illustrates a displayinterface 900 of an electronic device (such as the electronic device125, 135, and/or 145 with respect to FIG. 1 and/or the electronic device300 with respect to FIG. 3) for an automobile insurance risk assessmentrating (RAR) application (e.g., automobile insurance RAR application263). It is to be understood that the information discussed herein maybe conveyed in any suitable manner, and that the display interface 900shown in FIG. 9 is but one example.

As shown in FIG. 9, display interface 900 may include an information box902 that identifies the application and additional information 904 thatalerts the user that there has been a change in the user's automobileinsurance risk assessment rating. The display interface 900 may alsoinclude an interactive portion 906, which indicates to “PRESS HERE TOVIEW YOUR UPDATED AUTOMOBILE INSURANCE PREMIUM,” thereby enabling a userto view his/her updated automobile insurance risk assessment rating andupdated automobile insurance premium.

Additionally, the display interface 900 may include an interactiveportion 908, which indicates to “PRESS HERE FOR RECOMMENDATIONS TOIMPROVE YOUR RISK ASSESSMENT RATING,” thereby enabling a user to reviewrecommendations to improve his/her automobile insurance risk assessmentrating, thus decreasing his/her automobile insurance premium. Further,the display interface 900 may include an interactive portion 910, whichindicates “CANCEL,” thereby enabling a user to exit the application, toreturn to a prior screen, to exit to the home screen, etc.

Exemplary Computer-Implemented Method for Updating Insurance DataAssociated with a Target Vehicle

In one aspect, a computer-implemented method for an automobile insurancerisk assessment rating may be provided. The method may include one ormore processors (1) receiving telematics data associated with one ormore vehicles, the one or more vehicles including a target vehicle; (2)determining an average velocity of the other vehicles excluding thetarget vehicle; (3) comparing a velocity of the target vehicle to theaverage velocity of the other vehicles; and/or (4) updating insurancedata associated with the target vehicle or a driver associated with thetarget vehicle based upon the comparison of the velocity of the targetvehicle to the average velocity of the other vehicles. One or more ofthese aforementioned steps may also be repeated periodically, such thatthe insurance data is updated over time. The method may includeadditional, less, or alternate actions, including those discussedelsewhere herein.

For instance, in various aspects, the telematics data associated withthe one or more vehicles and the target vehicle may be generated by oneor more of (i) the vehicles and/or the target vehicle; (ii) anelectronic device located in one or more of the vehicles or the targetvehicle; and/or (iii) one or more smart infrastructure components.

Furthermore, aspects include the one or more vehicles being a subset ofa plurality of vehicles and, in such a case, the method may furtherinclude selecting the subset of the one or more vehicles used tocalculate the average velocity by identifying, from among the pluralityof vehicles, vehicles that share one or more common traits with thetarget vehicle. These common traits may include, for example, one ormore of: (i) traveling within a threshold distance of the targetvehicle; (ii) traveling in the same direction as the target vehicle;(iii) traveling at the same time of day as the target vehicle; (iv)traveling during the same day of the week as the target vehicle; and/or(v) traveling under the same weather conditions as the target vehicle

Still further, the method may include determining the average velocityof the other vehicles (excluding the target vehicle) by determining theaverage velocity of the other vehicles based upon historical telematicsdata, and comparing the velocity of the target vehicle to the averagevelocity of the other vehicles calculated based upon historicaltelematics data that identifies the other vehicles as traveling on thesame road, in the same direction, and during a time period that matchesthat of the target vehicle.

Additionally or alternatively, updating the insurance data associatedwith the target vehicle or a driver associated with the target vehiclemay include updating insurance premium pricing for the driver associatedwith the target vehicle.

Exemplary Remote Server for Updating Insurance Data Associated with aTarget Vehicle

In another aspect, a remote server for updating insurance data may beprovided. The remote server may include (1) a communication unitconfigured to receive telematics data associated with one or morevehicles, the one or more vehicles including a target vehicle; and (2) aprocessor unit configured to: (a) determine an average velocity of theother vehicles excluding the target vehicle; (b) compare, a velocity ofthe target vehicle to the average velocity of the other vehicles; and/or(c) update insurance data associated with the target vehicle or a driverassociated with the target vehicle based upon the comparison of thevelocity of the target vehicle to the average velocity of the othervehicles. One or more of these aforementioned steps may also be repeatedperiodically, such that the insurance data is updated over time. Theremote server may include additional, less, or alternate functionality,including that discussed elsewhere herein.

For instance, in various aspects, the telematics data associated withthe one or more vehicles and the target vehicle may be generated by oneor more of (i) the vehicles and/or the target vehicle; (ii) anelectronic device located in one or more of the vehicles or the targetvehicle; and/or (iii) one or more smart infrastructure components.

Furthermore, aspects include the one or more vehicles being a subset ofa plurality of vehicles and, in such a case, the processor unit may befurther configured to select the subset of the one or more vehicles usedto calculate the average velocity by identifying, from among theplurality of vehicles, vehicles that share one or more common traitswith the target vehicle. These common traits may include, for example,one or more of: (i) traveling within a threshold distance of the targetvehicle; (ii) traveling in the same direction as the target vehicle;(iii) traveling at the same time of day as the target vehicle; (iv)traveling during the same day of the week as the target vehicle; and/or(v) traveling under the same weather conditions as the target vehicle

Still further, the processor unit may be further configured to determinethe average velocity of the other vehicles (excluding the targetvehicle) by determining the average velocity of the other vehicles basedupon historical telematics data, and compare the velocity of the targetvehicle to the average velocity of the other vehicles calculated basedupon historical telematics data that identifies the other vehicles astraveling on the same road, in the same direction, and during a timeperiod that matches that of the target vehicle.

Additionally or alternatively, the processor unit may be furtherconfigured to update the insurance data associated with the targetvehicle or a driver associated with the target vehicle by updatinginsurance premium pricing for the driver associated with the targetvehicle.

Exemplary Non-Transitory Computer-Readable Medium for Updating InsuranceData Associated with a Target Vehicle

In yet another aspect, a tangible, non-transitory computer-readablemedium for updating insurance data may be provided. The tangible,non-transitory computer-readable medium (or media) may includeinstructions executable by one or more processors that, when executed bythe one or more processors, cause the one or more processors to (1)receive telematics data associated with one or more vehicles, the one ormore vehicles including a target vehicle; (2) determine an averagevelocity of the other vehicles excluding the target vehicle; (3) comparea velocity of the target vehicle to the average velocity of the othervehicles; and/or (4) update insurance data associated with the targetvehicle or a driver associated with the target vehicle based upon thecomparison of the velocity of the target vehicle to the average velocityof the other vehicles. The instructions may be executed by the one orprocessors in such a manner that one or more of the aforementioned stepsmay be repeated periodically, such that the insurance data is updatedover time. The instructions may direct additional, less, or alternatefunctionality, including that discussed elsewhere herein.

For instance, in various aspects, the telematics data associated withthe one or more vehicles and the target vehicle may be generated by oneor more of (i) the vehicles and/or the target vehicle; (ii) anelectronic device located in one or more of the vehicles or the targetvehicle; and/or (iii) one or more smart infrastructure components.

Furthermore, aspects include the one or more vehicles being a subset ofa plurality of vehicles and, in such a case, the instructions, whenexecuted by one or more processors, may further cause the one or moreprocessors to select the subset of the one or more vehicles used tocalculate the average velocity by identifying, from among the pluralityof vehicles, vehicles that share one or more common traits with thetarget vehicle. These common traits may include, for example, one ormore of: (i) traveling within a threshold distance of the targetvehicle; (ii) traveling in the same direction as the target vehicle;(iii) traveling at the same time of day as the target vehicle; (iv)traveling during the same day of the week as the target vehicle; and/or(v) traveling under the same weather conditions as the target vehicle

Still further, the instructions, when executed by one or moreprocessors, may further cause the one or more processors to determinethe average velocity of the other vehicles (excluding the targetvehicle) by determining the average velocity of the other vehicles basedupon historical telematics data, and to compare the velocity of thetarget vehicle to the average velocity of the other vehicles calculatedbased upon historical telematics data that identifies the other vehiclesas traveling on the same road, in the same direction, and during a timeperiod that matches that of the target vehicle.

Additionally or alternatively, the instructions, when executed by one ormore processors, may further cause the one or more processors to updatethe insurance data associated with the target vehicle or a driverassociated with the target vehicle by updating insurance premium pricingfor the driver associated with the target vehicle.

Additional Embodiments

In one aspect, a computer-implemented method for determining vehiclespeed differential from average traffic speed at a particular locationor in a given area may be provided. The method may include (1)receiving, using one or more processors and/or associated transceivers(such as via wireless communication or data transmission over one ormore radio links), a set of telematics data associated with a vehicleoperated by an individual and indicating a velocity and location (orarea/vicinity) of the vehicle; (2) receiving or determining, using theone or more processors, an average speed of traffic at or in thevicinity (e.g., 1, 2, or 5 miles) of the location of the vehicle; (3)calculating, using the one or more processors, a velocity differentialbased upon a difference between the average speed of traffic and thevelocity of the vehicle; and/or (4) determining, using the one or moreprocessors, a rating based upon the average velocity differential tofacilitate matching premium to risk, or lack thereof. The method mayinclude additional, less, or alternate actions, including thosediscussed elsewhere herein.

In another aspect, a computer system configured to determine speeddifferentials between flow of traffic and a particular vehicle may beprovided. The system may include one or more processors, sensors,transceivers, and servers configured to: (1) receive (such as viawireless communication or data transmission over one or more radiolinks) a set of telematics data associated with a vehicle operated by anindividual and indicating a velocity and location (or area/vicinity) ofthe vehicle; (2) receive (such as via wireless communication or datatransmission over one or more radio links) or otherwise determine anaverage speed of traffic at or in the vicinity (e.g., 1, 2, or 5 miles)of the location of the vehicle; (3) calculate a velocity differentialbased upon a difference between the average speed of traffic and thevelocity of the vehicle; and/or (4) determine a rating for the vehiclebased upon the average velocity differential. The system may beconfigured to include additional, less, or alternate functionality,including that discussed elsewhere herein.

In another aspect, a computer-implemented method for determining speeddifferential between the flow of traffic along a route and a particularvehicle may be provided. The method may include (1) receiving, using oneor more processors and/or associated transceivers, data detailingaverage traffic speed and direction of traffic flow at a given locationor an area (such as via wireless communication or data transmission overone or more radio links), the data being transmitted by one or moresmart or other vehicles, one or more mobile devices traveling withinvehicles, and/or one or more smart infrastructure sensors; (2)receiving, using the one or more processors and/or associatedtransceivers (such as via wireless communication or data transmissionover one or more radio links), a set of telematics data associated witha vehicle operated by an individual and indicating (i) a velocity, (ii)a direction of travel, and (iii) a location (or area/vicinity) of thevehicle, the location or area of the vehicle matching the location orarea associated with the average traffic speed, and the direction oftravel of the vehicle (as determined from the telematics data) matchingthe direction of traffic flow associated with the average traffic speed;(3) calculating, using the one or more processors, a velocitydifferential based upon a difference between the average traffic speedand the velocity of the vehicle; and/or (4) determining, using the oneor more processors, a rating based upon the average velocitydifferential to facilitate matching risk, or lack thereof, to premiumappropriately. The method may include additional, less, or alternateactions, including those discussed elsewhere herein.

In another aspect, a computer system configured to compare vehiclevelocity with average traffic speed of traffic in the vicinity may beprovided. The system may include one or more processors, sensors,transceivers, and/or servers configured to: (1) receive data detailingaverage traffic speed and direction of traffic flow at a given locationor an area (such as via wireless communication or data transmission overone or more radio links), the data being transmitted by one or moresmart or other vehicles, one or more mobile devices traveling withinvehicles, and/or one or more smart infrastructure sensors; (2) receive(such as via wireless communication or data transmission over one ormore radio links) a set of telematics data associated with a vehicleoperated by an individual and indicating (i) a velocity, (ii) adirection of travel, and (iii) a location (or area/vicinity) of thevehicle, the location or area of the vehicle matching the location orarea associated with the average traffic speed, and the direction oftravel of the vehicle (as determined from the telematics data) matchingthe direction of traffic flow associated with the average traffic speed;(3) calculate a velocity differential based upon a difference betweenthe average traffic speed and the velocity of the vehicle; and/or (4)determine a rating based upon the average velocity differential tofacilitate matching risk, or lack thereof, to premium appropriately. Thesystem may include additional, less, or alternate functionality,including that discussed elsewhere herein.

In an additional aspect, a computer-implemented method is provided. Themethod may include (1) receiving, using one or more processors,telematics data associated with one or more vehicles, the one or morevehicles including a target vehicle; (2) determining, using the one ormore processors, an average velocity of the other vehicles excluding thetarget vehicle; (3) comparing, using the one or more processors, avelocity of the target vehicle to the average velocity of the othervehicles; and/or (4) updating, using the one or more processors,insurance data associated with the target vehicle or a driver associatedwith the target vehicle based upon the comparison of the velocity of thetarget vehicle to the average velocity of the other vehicles. The methodmay include additional, less, or alternate actions, including thosediscussed elsewhere herein.

In yet another aspect, a remote server is provided. The remote servermay include (1) a communication unit configured to receive telematicsdata associated with one or more vehicles, the one or more vehiclesincluding a target vehicle; and (2) a processor unit configured to: (i)determine an average velocity of the other vehicles excluding the targetvehicle; (ii) compare, a velocity of the target vehicle to the averagevelocity of the other vehicles; and (iii) update insurance dataassociated with the target vehicle or a driver associated with thetarget vehicle based upon the comparison of the velocity of the targetvehicle to the average velocity of the other vehicles. The remote servermay include additional, less, or alternate components, including thosediscussed elsewhere herein.

In still another aspect, a tangible, non-transitory computer-readablemedium may be provided. The tangible, non-transitory computer-readablemedium may include instructions executable by one or more processorsthat, when executed by the one or more processors, cause the one or moreprocessors to (i) receive telematics data associated with one or morevehicles, the one or more vehicles including a target vehicle; (ii)determine an average velocity of the other vehicles excluding the targetvehicle; (iii) compare a velocity of the target vehicle to the averagevelocity of the other vehicles; and (iv) update insurance dataassociated with the target vehicle or a driver associated with thetarget vehicle based upon the comparison of the velocity of the targetvehicle to the average velocity of the other vehicles. Thenon-transitory computer-readable medium may include additional, less, oralternate instructions, including those discussed elsewhere herein.

Additional Considerations

As used herein, the term “vehicle” is used interchangeably with“automobile” and the term “automobile” refers to any type of poweredtransportation device, which includes, but is not limited to, a car,truck, bus, motorcycle, or boat—including fully or partiallyself-driving (i.e., autonomous or semi-autonomous) vehicles. While avehicle may be described herein as being controlled by an operator orinsured individual, the aspects described herein also apply toautonomous vehicles that may be unmanned and/or operated remotely or inanother suitable fashion, such as via controls other than the steeringwheel, gear shift, brake pedal, and accelerator pedal.

The systems and methods described herein are directed to an improvementto computer functionality, and improve the functioning of conventionalcomputers.

With the foregoing, an insurance customer may opt-in to a rewards,insurance discount, or other type of program. After the insurancecustomer provides their affirmative consent, an insurance providerremote server may collect data from the customer's mobile device,on-board vehicle computer, or other devices—such as with the customer'spermission or affirmative consent. The data collected may be related tovehicle functionality (or vehicle occupant preferences or preferenceprofiles) or vehicle operation, and/or insured assets before (and/orafter) an insurance-related event, including those events discussedelsewhere herein. In return, risk averse insureds, vehicle owners, orvehicle occupants may receive discounts or insurance cost savingsrelated to auto insurance, as well as home, renters, personal articles,and other types of insurance from the insurance provider.

In one aspect, smart or interconnected vehicle data, and/or other data,including the types of data discussed elsewhere herein, may be collectedor received by an insurance provider remote server, such as via director indirect wireless communication or data transmission from an on-boardvehicle computer, mobile device, or other customer computing device,after a customer affirmatively consents or otherwise opts-in to aninsurance discount, reward, or other program. The insurance provider maythen analyze the data received with the customer's permission to providebenefits to the customer. As a result, risk averse customers may receiveinsurance discounts or other insurance cost savings based upon data thatreflects low risk behavior and/or technology that mitigates or preventsrisk to (i) insured assets, such as homes, personal belongings, orvehicles, and/or (ii) vehicle, home, or apartment occupants.

This detailed description is to be construed as exemplary only and doesnot describe every possible embodiment, as describing every possibleembodiment would be impractical, if not impossible. One may be implementnumerous alternate embodiments, using either current technology ortechnology developed after the filing date of this application.

Furthermore, although the present disclosure sets forth a detaileddescription of numerous different embodiments, it should be understoodthat the legal scope of the description is defined by the words of theclaims set forth at the end of this patent and equivalents. The detaileddescription is to be construed as exemplary only and does not describeevery possible embodiment since describing every possible embodimentwould be impractical. Numerous alternative embodiments may beimplemented, using either current technology or technology developedafter the filing date of this patent, which would still fall within thescope of the claims. Although the following text sets forth a detaileddescription of numerous different embodiments, it should be understoodthat the legal scope of the description is defined by the words of theclaims set forth at the end of this patent and equivalents. The detaileddescription is to be construed as exemplary only and does not describeevery possible embodiment since describing every possible embodimentwould be impractical. Numerous alternative embodiments may beimplemented, using either current technology or technology developedafter the filing date of this patent, which would still fall within thescope of the claims.

The following additional considerations apply to the foregoingdiscussion. Throughout this specification, plural instances mayimplement components, operations, or structures described as a singleinstance. Although individual operations of one or more methods areillustrated and described as separate operations, one or more of theindividual operations may be performed concurrently, and nothingrequires that the operations be performed in the order illustrated.Structures and functionality presented as separate components in exampleconfigurations may be implemented as a combined structure or component.Similarly, structures and functionality presented as a single componentmay be implemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter herein.

Additionally, certain embodiments are described herein as includinglogic or a number of routines, subroutines, applications, orinstructions. These may constitute either software (e.g., code embodiedon a machine-readable medium or in a transmission signal) or hardware.In hardware, the routines, etc., are tangible units capable ofperforming certain operations and may be configured or arranged in acertain manner. In exemplary embodiments, one or more computer systems(e.g., a standalone, client or server computer system) or one or morehardware modules of a computer system (e.g., a processor or a group ofprocessors) may be configured by software (e.g., an application orapplication portion) as a hardware module that operates to performcertain operations as described herein.

In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that is permanently configured(e.g., as a special-purpose processor, such as a field programmable gatearray (FPGA) or an application-specific integrated circuit (ASIC)) toperform certain operations. A hardware module may also compriseprogrammable logic or circuitry (e.g., as encompassed within ageneral-purpose processor or other programmable processor) that istemporarily configured by software to perform certain operations. Itwill be appreciated that the decision to implement a hardware modulemechanically, in dedicated and permanently configured circuitry, or intemporarily configured circuitry (e.g., configured by software) may bedriven by cost and time considerations.

Accordingly, the term “hardware module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured (e.g., hardwired), or temporarilyconfigured (e.g., programmed) to operate in a certain manner or toperform certain operations described herein. Considering embodiments inwhich hardware modules are temporarily configured (e.g., programmed),each of the hardware modules need not be configured or instantiated atany one instance in time. For example, where the hardware modulescomprise a general-purpose processor configured using software, thegeneral-purpose processor may be configured as respective differenthardware modules at different times. Software may accordingly configurea processor, for example, to constitute a particular hardware module atone instance of time and to constitute a different hardware module at adifferent instance of time.

Hardware modules may provide information to, and receive informationfrom, other hardware modules. Accordingly, the described hardwaremodules may be regarded as being communicatively coupled. Where multipleof such hardware modules exist contemporaneously, communications may beachieved through signal transmission (e.g., over appropriate circuitsand buses) that connect the hardware modules. In embodiments in whichmultiple hardware modules are configured or instantiated at differenttimes, communications between such hardware modules may be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module may perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further hardware module may then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules may also initiate communications with input oroutput devices, and may operate on a resource (e.g., a collection ofinformation).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods or routines described herein may be at leastpartially processor-implemented. For example, at least some of theoperations of a method may be performed by one or more processors orprocessor-implemented hardware modules. The performance of certain ofthe operations may be distributed among the one or more processors, notonly residing within a single machine, but deployed across a number ofmachines. In some example embodiments, the processor or processors maybe located in a single location (e.g., within a home environment, anoffice environment or as a server farm), while in other embodiments theprocessors may be distributed across a number of locations.

The performance of certain of the operations may be distributed amongthe one or more processors, not only residing within a single machine,but deployed across a number of machines. In some exemplary embodiments,the one or more processors or processor-implemented modules may belocated in a single geographic location (e.g., within a vehicle, withina home environment, an office environment, or a server farm). In otherexample embodiments, the one or more processors or processor-implementedmodules may be distributed across a number of geographic locations.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or a combination thereof), registers, or othermachine components that receive, store, transmit, or displayinformation.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. For example, some embodimentsmay be described using the term “coupled” to indicate that two or moreelements are in direct physical or electrical contact. The term“coupled,” however, may also mean that two or more elements are not indirect contact with each other, but yet still co-operate or interactwith each other. The embodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the description. Thisdescription, and the claims that follow, should be read to include oneor at least one and the singular also includes the plural unless it isobvious that it is meant otherwise.

The patent claims at the end of this patent application are not intendedto be construed under 35 U.S.C. § 112(f) unless traditionalmeans-plus-function language is expressly recited, such as “means for”or “step for” language being explicitly recited in the claim(s).

1. A computer-implemented method, comprising: receiving, by one or moreprocessors, telematics data associated with a target vehicle and aplurality of other nearby vehicles, the plurality of other nearbyvehicles being within a threshold distance of the target vehicle;determining, by the one or more processors, a velocity and a directionof the target vehicle based upon the telematics data; identifying, bythe one or more processors, a subset of the plurality of other nearbyvehicles traveling in the direction of the target vehicle based upon thetelematics data; determining, by the one or more processors, an averagevelocity of the subset of the plurality of other nearby vehicles basedupon the telematics data; comparing, by the one or more processors, thevelocity of the target vehicle to the average velocity of the subset ofthe plurality of other nearby vehicles; upon determining the velocity ofthe target vehicle is within a threshold range of the average velocity,decreasing, by the one or more processors, an insurance risk assessmentrating associated with the target vehicle or a driver of the targetvehicle; and presenting, using an electronic device associated with thedriver of the target vehicle, the decreased insurance risk assessment tothe driver of the target vehicle; wherein receiving the telematics dataincludes receiving geographic location data of the target vehicle andthe plurality of other nearby vehicles from one or more satellites usinga global navigation satellite system.
 2. The computer-implemented methodof claim 1, wherein the telematics data are generated by one or more of:(i) the target vehicle or the plurality of other nearby vehicles; (ii)an electronic device located in the target vehicle or the plurality ofother nearby vehicles; and (iii) one or more smart infrastructurecomponents.
 3. The computer-implemented method of claim 1, wherein thesubset of the plurality of other nearby vehicles share one or morecommon driving conditions with the target vehicle.
 4. Thecomputer-implemented method of claim 3, wherein the one or more commondriving conditions includes one of: (i) traveling at a same time of dayas the target vehicle; (ii) traveling during a same day of week as thetarget vehicle; and (iii) traveling under a same weather condition asthe target vehicle.
 5. The computer-implemented method of claim 1,wherein determining the average velocity of the subset of the pluralityof other nearby vehicles is further based upon historical telematicsdata, the historical telematics data identifying the subset of theplurality of other nearby vehicles traveling on a same road, in a samedirection, and during a time period that matches that of the targetvehicle.
 6. The computer-implemented method of claim 1, furthercomprising: upon determining the velocity of the target vehicle iswithin the threshold range of the average velocity, reducing insurancepremium pricing for the driver of the target vehicle.
 7. Thecomputer-implemented method of claim 1, wherein receiving the telematicsdata, determining the velocity and the direction of the target vehicle,identifying the subset of the plurality of other nearby vehicles,determining the average velocity of the subset of the plurality of othernearby vehicles, and comparing the velocity of the target vehicle to theaverage velocity of the subset of the plurality of other nearby vehiclesare repeated periodically such that the insurance data is updated overtime.
 8. A server, comprising: one or more processors; and a memorystoring instructions that, when executed by the one or more processors,cause the one or more processors to: receive telematics data associatedwith a target vehicle and a plurality of other nearby vehicles, theplurality of other nearby vehicles being within a threshold distance ofthe target vehicle; determine a velocity and a direction of the targetvehicle based upon the telematics data; identify a subset of theplurality of other nearby vehicles traveling in the direction of thetarget vehicle based upon the telematics data; determine an averagevelocity of the subset of the plurality of other nearby vehicles basedupon the telematics data; compare the velocity of the target vehicle tothe average velocity of the subset of the plurality of other nearbyvehicles; upon determining the velocity of the target vehicle is withina threshold range of the average velocity, decrease an insurance riskassessment rating associated with the target vehicle or a driver of thetarget vehicle; and present, using an electronic device associated withthe driver of the target vehicle, the decreased insurance riskassessment to the driver of the target vehicle; wherein to receive thetelematics data includes to receive geographic location data of thetarget vehicle and the plurality of other nearby vehicles from one ormore satellites using a global navigation satellite system.
 9. Theserver of claim 8, wherein the telematics data are generated by one ormore of: (i) the target vehicle or the plurality of other nearbyvehicles; (ii) an electronic device located in the target vehicle or theplurality of other nearby vehicles; and (iii) one or more smartinfrastructure components.
 10. The remote server of claim 8, wherein thesubset of the plurality of other nearby vehicles share one or morecommon driving conditions with the target vehicle.
 11. The server ofclaim 10, wherein the one or more common driving conditions includes oneof: (i) traveling at a same time of day as the target vehicle; (ii)traveling during a same day of week as the target vehicle; and (iii)traveling under a same weather condition as the target vehicle.
 12. Theserver of claim 8, wherein the instructions, when executed by the one ormore processors, that cause the one or more processors to determine theaverage velocity of the subset of the plurality of other nearby vehiclesis further based upon historical telematics data, the historicaltelematics data identifying the subset of the plurality of other nearbyvehicles traveling on a same road, in a same direction, and during atime period that matches that of the target vehicle.
 13. The server ofclaim 8, wherein the instructions, when executed by the one or moreprocessors, further cause the one or more processors to, upondetermining the velocity of the target vehicle is within the thresholdrange of the average velocity, reducing insurance premium pricing forthe driver of the target vehicle.
 14. The server of claim 8, wherein theinstructions, when executed by the one or more processors, further causethe one or more processors to periodically repeat receiving thetelematics data, determining the velocity and the direction of thetarget vehicle, identifying the subset of the plurality of other nearbyvehicles, determining the average velocity of the subset of theplurality of other nearby vehicles, and comparing the velocity of thetarget vehicle to the average velocity of the subset of the plurality ofother nearby vehicles such that the insurance data is updated over time.15. A tangible, non-transitory, computer-readable medium storinginstructions that, when executed by one or more processors, cause theone or more processors to: receive telematics data associated with atarget vehicle and a plurality of other nearby vehicles, the pluralityof other nearby vehicles being within a threshold distance of the targetvehicle; determine a velocity and a direction of the target vehiclebased upon the telematics data; identify a subset of the plurality ofother nearby vehicles traveling in the direction of the target vehiclebased upon the telematics data; determine an average velocity of thesubset of the plurality of other nearby vehicles based upon thetelematics data; compare the velocity of the target vehicle to theaverage velocity of the subset of the plurality of other nearbyvehicles; upon determining the velocity of the target vehicle is withina threshold range of the average velocity, decrease an insurance riskassessment rating associated with the target vehicle or a driver of thetarget vehicle; and present, using an electronic device associated withthe driver of the target vehicle, the decreased insurance riskassessment to the driver of the target vehicle; wherein to receive thetelematics data includes to receive geographic location data of thetarget vehicle and the plurality of other nearby vehicles from one ormore satellites using a global navigation satellite system.
 16. Thetangible, non-transitory, computer-readable medium of claim 15, whereinthe telematics are generated by one or more of: (i) the target vehicleor the plurality of other nearby vehicles; (ii) an electronic devicelocated in the target vehicle or the plurality of other nearby vehicles;and (iii) one or more smart infrastructure components.
 17. The tangible,non-transitory, computer-readable medium of claim 16, wherein the subsetof the plurality of other nearby vehicles share one or more commondriving conditions with the target vehicle.
 18. The tangible,non-transitory, computer-readable medium of claim 17, wherein the one ormore common driving conditions includes one of: (i) traveling at a sametime of day as the target vehicle; (ii) traveling during a same day ofweek as the target vehicle; and (iii) traveling under a same weathercondition as the target vehicle.
 19. The tangible, non-transitory,computer-readable medium of claim 17, wherein the instructions todetermine the average velocity of the subset of the plurality othernearby vehicles further include instructions that, when executed by theone or more processors, cause the one or more processors to determinethe average velocity of the subset of the plurality of other nearbyvehicles based upon historical telematics data, the historicaltelematics data identifying the subset of the plurality of other nearbyvehicles traveling on a same road, in a same direction, and during atime period that matches that of the target vehicle.
 20. The tangible,non-transitory, computer-readable medium of claim 15, when executed bythe one or more processors, further cause the one or more processors to,upon determining the velocity of the target vehicle is within thethreshold range of the average velocity, reduce insurance premiumpricing for the driver of the target vehicle.
 21. The tangible,non-transitory, computer-readable medium of claim 15, further includinginstructions that, when executed by the one or more processors, causethe one or more processors to periodically repeat receiving thetelematics data, determining the velocity and the direction of thetarget vehicle, identifying the subset of the plurality of other nearbyvehicles, determining the average velocity of the subset of theplurality of other nearby vehicles, and comparing the velocity of thetarget vehicle to the average velocity of the subset of the plurality ofother nearby vehicles such that the insurance data is updated over time.